Migliorare la qualità di Jami

Test unitari

  • È più difficile fare un test unitario sul progetto Jami a causa delle condizioni di gara sulla dipendenza a più livelli.

  • 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

  • Bisogna implementare un sistema per convincere il team a fare un test unitario per un nuovo codice prima di fondersi.

  • È possibile avviare eseguendo make check nella cartella daemon o separatamente nella cartella di test unitario con gdb: gdb ut_media_encoder

  • L’ambiente deve essere impostato con – disable-shared durante il comando./configure

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

Test di integrazione

  • Ogni commit passa attraverso test di integrazione in dockers sulle macchine di costruzione si possono trovare i dettagli su: jenkins.jami.net

  • La revisione del codice viene effettuata da un altro sviluppatore, a volte il codice viene rivisto dallo stesso sviluppatore, questo dovrebbe essere evitato per enfatizzare la legge di Linus.

  • Sonarqube consente a Jenkins di costruire Jami e verificare il linting. Puoi trovare filtri e risultati su: sonar- jami.savoirfairelinux.net Sonar utilizza clang-tidy come compilatore di linting preprocessore, puoi trovare filtri clangs nel file.clang-tidy nella cartella daemon.

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

Doc e feedback:

  • Puoi trovare tutta la documentazione su docs.jami.net

  • Le questioni sono presentate dagli sviluppatori o dagli utenti su git.jami.net

Agente.

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)

Test di fumo

Prima di rilasciare ogni cliente deve passare attraverso una lista di scenari.

I scenari sono descritti qui: [testi di fumo di Jami]

Sono esaminati da QA dpt. prima di inviarli agli sviluppatori se necessario.

Se un rilascio contiene un commit di rete che è stato fuso, il dipartimento QA dovrebbe essere in grado di automatizzare i diversi test di connettività (come descritto di seguito nelle configurazioni di chiamate)

Chiama le configurazioni.

Questo è il elenco delle configurazioni di rete che devono essere testate:

(IPv4 IPv6) + (TURN !TURN) + (STUN !STUN) + (UPnP !UPnP) per entrambe le parti.

Se entrambe le parti sono IPv4 solo senza TURN/STUN/UPnP, la chiamata dovrebbe essere solo locale.

Cosa deve essere fatto

  • Imposta un sistema all’interno del team per garantire la manutenzione e la creazione di test unitari.

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

  • Ogni nuova funzionalità dovrebbe essere testata su ogni piattaforma prima di essere unita per ridurre la regressione

  • Integrare sonarqube su ogni cliente

  • Automatizzare il test del comportamento di Jami sulla compatibilità con la rete