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.

  • We use lcov for the coverage, you can find the lcov’s configuration in the daemon’s Makefile.am. Also, the coverage can be found at https://docs.jami.net/coverage/ and https://dl.jami.net/docs/dhtnet/coverage

  • 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

  • Clients also have tests (cf jami-client-qt/tests for Desktop, jami-client-android/jami-android/app/src/androidTest for Android)

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.

  • On SFLVault sonarqube can be found at service m#2637 and admin logins at 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

Agent

Every night, hundred of calls are tested via 2 Agents and a message is posted every morning in the chat with the result (if all call succeeded or not)

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.

Ce qui doit être fait

  • Établir un système au sein de l’équipe pour assurer la maintenance et la création de tests unitaires.

  • Each major functionality should be tested as whole by adding a test (i.e. making sure a message was received, the call was ended well on both side, 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