Mejorar la calidad de Jami

Pruebas unitarias

  • Es más difícil hacer pruebas unitarias en el proyecto Jami debido a las condiciones de carrera en dependencia de varios niveles.

  • 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

  • Se necesita implementar un sistema para convencer al equipo de hacer una prueba de unidad para un nuevo código antes de fusionarse.

  • Puede lanzarlos haciendo make check en la carpeta de daemon o por separado en la carpeta de prueba de unidad con gdb: gdb ut_media_encoder

  • El entorno debe ser configurado con –disable-shared durante el comando./configure

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

Pruebas de integración

  • Cada compromiso pasa por pruebas de integración en los dockers de las máquinas de construcción.

  • La revisión del código es realizada por un compañero de desarrollo, a veces el código es revisado por el mismo desarrollador, esto debe evitarse para enfatizar la ley Linus.

  • Sonarqube permite a Jenkins construir Jami y verificar el linting. Puede encontrar filtros y resultados en: sonar- jami.savoirfairelinux.net Sonar utiliza clang-tidy como compilador de linting de preprocesador, puede encontrar filtros de clangs en el archivo.clang-tidy en la carpeta de daemon.

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

Doc y comentarios:

  • Puede encontrar toda la documentación en docs.jami.net

  • Los problemas son planteados por los desarrolladores o usuarios en git.jami.net

Agente, ¿ qué?

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)

Pruebas de humo

Antes de que cada uno de los clientes se libere, debe pasar por una lista de escenarios.

Los escenarios se describen aquí: [pruebas de humo de jamie]

Se revisan por QA dpt. antes de enviarlo a los desarrolladores si es necesario.

Si una versión contiene un compromiso de red que se ha fusionado, el departamento de calificación debe ser capaz de automatizar las diferentes pruebas de conectividad (como se describe a continuación en las configuraciones de llamadas)

Llama a las configuraciones.

Esta es la lista de configuraciones de red que deben ser probadas:

(IPv4 IPv6) + (TURN !TURN) + (STUN !STUN) + (UPnP !UPnP) para ambas partes.

Si ambos lados son IPv4 solamente sin TURN/STUN/UPnP, la llamada debe ser local.

Lo que hay que hacer

  • Establecer un sistema dentro del equipo para garantizar el mantenimiento y la creación de pruebas unitarias.

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

  • Cada nueva funcionalidad debe ser probada en cada plataforma antes de fusionarla para reducir la regresión

  • Integrar sonarcube en cada cliente

  • Automatizar la prueba del comportamiento de Jamis en la compatibilidad de la red