Amélioration de la qualité de Jami

Tests unitaires

Il est plus difficile de faire un test unitaire sur le projet Jami en raison des conditions de course sur la dépendance à plusieurs niveaux.
Il y a environ 30 tests unitaires et une couverture de 26%. En raison de la forte demande de Jami pour donner de nouvelles fonctionnalités à l’utilisateur rapidement, elles ne sont pas maintenues par les développeurs ou par un département de QA.
Nous utilisons lcov pour la couverture, vous pouvez trouver la configuration de lcovs dans le daemons Makefile.am.
Un système doit être mis en place pour commencer à convaincre l’équipe de faire un test unitaire pour un nouveau code avant de fusionner
Vous pouvez les lancer en faisant make check dans le dossier daemon ou séparément dans le dossier test unitaire avec gdb: gdb ut_media_encoder
L’environnement doit être réglé avec –disable-shared pendant la commande./configurer

Tests de cadre

Vous pouvez trouver des tests de framework dans le daemon Makefile.am et le déjeuner avec make integration. Cela appelle le script jami_test.py dans le dossier outils/dringctrl. Il utilise dringctrl.py et controller.py qui vous permettent de contrôler Jami via bash.
Cela fait une série d’appels pour s’assurer que le réseau ouvert de Jami” est stable.
D’autres tests-cadres doivent être mis en œuvre à l’avenir pour tester les fonctionnalités de Jami dans leur ensemble.

Tests d’intégration

Chaque commande passe par des tests d’intégration dans les dockers des machines de construction. Vous pouvez trouver les détails à: jenkins.jami.net
Le code-révision est effectuée par un développeur collègue, parfois le code est révisé par le même développeur, cela doit être évité pour mettre l’accent sur la loi Linus.
Sonarqube permet à Jenkins de construire Jami et de vérifier le linting. Vous pouvez trouver des filtres et des résultats à: sonar- jami.savoirfairelinux.net Sonar utilise clang-tidy comme un préprocesseur de linting compilateur, vous pouvez trouver des filtres clangs dans le fichier.clang-tidy dans le dossier daemon.
Sur sflvault sonarqube peut être trouvé au service m#2637 et aux connexions d’administration au service s#7169

Doc et les commentaires:

Vous pouvez trouver toute la documentation sur docs.jami.net
Les problèmes sont posés par les développeurs ou les utilisateurs sur git.jami.net

Surveillance

Un script est appelé toutes les 30 minutes sur une machine virtuelle jami-monitorpeervm-01. Vous pouvez le trouver sur le service s#7209 et appelle un autre client virtuel jami-monitorpeer-02 (service s#7224). Une série d’appels est faite et il renvoie le taux d’échec. Vous pouvez trouver tous les détails à https://wiki.savoirfairelinux.com/wiki/Jami-monitorpeervm-01.mt.sfl.
Si nécessaire, la commande manuelle est./script.sh peer 031acbb73f2a3385b2babc7161f13325be103431
Il suit un graphique de point par point en temps réel sur https://monitoring.savoirfairelinux.com/grafana/dashboard/script/dyndash.js?host=jami-monitorpeervm-01.mtl.sfl&service=Check%20JamiCall&panelId=1&fullscreen&orgId=1

Tests de fumée

Avant de sortir, chaque client doit passer par une liste de scénarios.

Les scénarios sont décrits ici: [test de fumée de Jami]

Ils sont examinés par QA dpt. avant de l’envoyer aux développeurs si nécessaire.

Si une version contient un commande réseau qui a été fusionné, le département d’AQ doit être en mesure d’automatiser les différents tests de connectivité (comme décrit ci-dessous dans les configurations Appels)

Il appelle les configurations.

Voici la liste des configurations de réseau à tester:

(IPv4! IPv6) + (TURN!! TURN) + (STUN!! STUN) + (UPnP!! UPnP) pour les deux côtés.

Si les deux parties sont IPv4 uniquement sans TURN/STUN/UPnP, l’appel doit être local.

Note spéciale: FDroid

Le script pour générer MR est dans le repo client-android (fdroidMergeRequest.sh)

Ce qui doit être fait

Poussez la couverture à 60%
Établir un système au sein de l’équipe pour assurer la maintenance et la création de tests unitaires.
Chaque fonctionnalité majeure doit être testée dans son ensemble en ajoutant un test cadre (c’est-à-dire en s’assurant que le message a été reçu, que l’appel a été terminé bien des deux côtés, etc…)
Chaque nouvelle fonctionnalité doit être testée sur chaque plateforme avant de la fusionner pour réduire la régression.
Intégrer sonarqube sur chaque client
Automatiser le test du comportement de Jami sur la compatibilité réseau
Faites un script make_ring.py adapté aux fenêtres aussi