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.
Usamos lcov para la cobertura, puede encontrar la configuración del lcov en el demonio Makefile.am. Además, la cobertura se puede encontrar en https://docs.jami.net/coverage/ y 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
Los clientes también tienen pruebas (consulte “jami-client-qt
tests' para escritorio,jami-client-android/jami-android/app/src/androidTest` para 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.
En SFLVault, sonarqube se puede encontrar en el servicio m#2637 y los inicios de sesión de administrador en los servicios#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é?
Cada noche, cientos de llamadas se prueban a través de 2 Agentes y se publica un mensaje todas las mañanas en el chat con el resultado (si todas las llamadas tuvieron éxito o no)
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.
Cada funcionalidad principal debe probarse en su totalidad agregando una prueba (es decir, asegurándose de que se recibió un mensaje, la llamada finalizó bien en ambos lados, 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