Melhorar a qualidade da Jami

Teste unitário

  • É mais difícil fazer testes unitários no projeto Jami devido às condições de corrida sobre dependência de vários níveis.

  • Usamos o lcov para a cobertura, pode encontrar a configuração do lcov no Makefile.am do daemon. Além disso, a cobertura pode ser encontrada em https://docs.jami.net/coverage/ e https://dl.jami.net/docs/dhtnet/coverage

  • Um sistema precisa ser implementado para começar a convencer a equipa a fazer um teste unitário para o novo código antes de se fundir

  • Você pode lançá-los fazendo make check na pasta daemon ou separadamente na pasta de teste unitário com gdb: gdb ut_media_encoder

  • O ambiente precisa ser definido com –disable-shared durante o comando./configure

  • Os clientes também têm testes (cf jami-client-qt/tests para Desktop, jami-client-android/jami-android/app/src/androidTest para Android)

Testes de integração

  • Cada compromisso passa por testes de integração em dockers nas máquinas de construção.

  • A revisão de código é feita por um colega desenvolvedor, às vezes o código é revisado pelo mesmo desenvolvedor, o que deve ser evitado para enfatizar a lei de Linus. O rótulo “verificado por Jenkins” às vezes é descartado e substituído por +1 de um desenvolvedor, o que também deve ser evitado.

  • Sonarqube permite que Jenkins construa Jami e verifique o linting. Você pode encontrar filtros e resultados em: sonar- jami.savoirfairelinux.net Sonar usa clang-tidy como um compilador de linting de pré-processador, você pode encontrar filtros de clangs no arquivo.clang-tidy na pasta daemon.

  • No SFLVault, o sonarqube pode ser encontrado no serviço m#2637 e os logins de administrador no serviço s#7169

Doc e feedback:

  • Pode encontrar toda a documentação no docs.jami.net

  • As questões são feitas por desenvolvedores ou usuários em git.jami.net

Agente.

Todas as noites, centenas de chamadas são testadas por 2 agentes e todas as manhãs é publicada uma mensagem na conversação com o resultado (se todas as chamadas foram bem sucedidas ou não)

Teste de fumo

Antes de cada lançamento, todos os clientes devem passar por uma lista de cenários.

Os cenários são descritos aqui: Testes de fumaça de Jami

São revisadas pela QA dpt. antes de enviá-las aos desenvolvedores, se necessário.

Se uma versão contém um compromisso de rede que foi fundido, o departamento de QA deve ser capaz de automatizar os diferentes testes de conectividade (como descrito abaixo nas configurações de chamadas)

Chama configurações.

Esta é a lista das configurações de rede que devem ser testadas:

(IPv4 IPv6) + (TURN !TURN) + (STUN !STUN) + (UPnP !UPnP) para ambos os lados.

Se ambos os lados forem IPv4 apenas sem TURN/STUN/UPnP, a chamada deve ser apenas local.

O que é necessário fazer

  • Estabelecer um sistema dentro da equipa para assegurar a manutenção e a criação de testes unitários.

  • Cada funcionalidade principal deve ser testada como um todo, adicionando um teste (ou seja, certificar-se de que uma mensagem foi recebida, que a chamada foi terminada corretamente em ambos os lados, etc…)

  • Cada nova funcionalidade deve ser testada em cada plataforma antes de ser combinada para reduzir a regressão

  • Integrar sonarqube em cada cliente

  • Automatizar o teste do comportamento da Jami sobre a compatibilidade com a rede