Het verbeteren van de kwaliteit van Jami

Eenheidsonderzoek

  • Het is moeilijker om eenheidstests te doen op het Jami-project vanwege de raceomstandigheden op de meervlakke afhankelijkheid.

  • 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

  • Een systeem moet worden ingevoerd om het team te overtuigen om een eenheidstest te doen voor nieuwe code voordat ze worden samengevoegd.

  • Je kunt ze starten door te doen make check in de daemon map of apart in de eenheidstest map met gdb: gdb ut_media_encoder

  • De omgeving moet worden ingesteld met –disable-shared tijdens het./configure commando

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

Integratieproeven

  • Elke commit gaat door integratietests in dockers op de bouwmachines.

  • Code-review wordt gedaan door een mede-ontwikkelaar, soms wordt de code door dezelfde ontwikkelaar beoordeeld, dit moet worden vermeden om Linus wet te benadrukken.

  • Sonarqube laat Jenkins Jami bouwen en linting verifiëren. Je kunt filters en resultaten vinden op: sonar- jami.savoirfairelinux.net Sonar gebruikt clang-tidy als een preprocessor linting compiler, je kunt clangs filters vinden in.clang-tidy bestand in de daemon map.

  • On SFLVault sonarqube can be found at service m#2637 and admin logins at service s#7169

Doc en feedback:

  • Alle documentatie is te vinden op docs.jami.net

  • Problemen worden gesteld door ontwikkelaars of gebruikers op 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)

Rookproeven

Voordat elk release, moeten alle klanten een lijst van scenario’s doorgaan.

De scenario’s zijn hier beschreven: [Jami rook testen]

Ze worden door QA dpt beoordeeld voordat ze naar de ontwikkelaars worden gestuurd indien nodig.

Als een release een netwerkcommit bevat die is samengevoegd, moet de QA-afdeling in staat zijn om de verschillende connectiviteitstests te automatiseren (zoals hieronder beschreven in Calls-configuraties).

Roept op opstellingen.

Dit is de lijst van netwerkconfiguraties die moeten worden getest:

(IPv4 IPv6) + (TURN !TURN) + (STUN !STUN) + (UPnP !UPnP) voor beide kanten.

Als beide partijen alleen IPv4 hebben zonder TURN/STUN/UPnP, moet de oproep alleen lokaal zijn.

Wat moet worden gedaan

  • Een systeem opzetten binnen het team om onderhoud en de oprichting van eenheidstesten te waarborgen.

  • 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…)

  • Elke nieuwe functionaliteit moet op elk platform worden getest voordat ze wordt samengevoegd om de regressie te verminderen.

  • Integreer sonarqube op elke klant

  • Automatiseren van het testen van het gedrag van Jami’s op netwerkcompatibiliteit