Melhorar a qualidade do Jami
Teste unitário
É mais difícil fazer testes unitários no projeto Jami devido às condições de corrida na 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
É necessário implementar um sistema para começar a convencer a equipa a fazer um teste unitário do novo código antes de o fundir
Pode lançá-los fazendo “make check” na pasta daemon ou separadamente na pasta unit-test com gdb: “gdb ut_media_encoder”
O ambiente tem de ser definido com “–disable-shared” durante o comando “./configure”
Os clientes também têm testes (cf
jami-client-qt/testspara Desktop,jami-client-android/jami-android/app/src/androidTestpara Android)
Testes de integração
Cada commit passa por testes de integração em dockers nas máquinas de compilação. Pode encontrar os detalhes em: jenkins.jami.net
A revisão de código é feita por um colega programador, por vezes o código é revisto pelo mesmo programador, isto deve ser evitado para enfatizar a lei de Linus. A etiqueta “Jenkins verified” é por vezes descartada e substituída por +1 de um programador, o que também deve ser evitado.
O Sonarqube permite que o Jenkins compile o Jami e verifique o linting. Pode encontrar filtros e resultados em: sonar- jami.savoirfairelinux.net O Sonar utiliza o clang-tidy como compilador de linting do pré-processador, pode encontrar os filtros do clang no ficheiro .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
Documentação e comentários:
Pode encontrar toda a documentação em docs.jami.net
Os erros são reportados por programadores ou utilizadores 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 uma lista de cenários.
Os cenários são descritos aqui: Jami smoke tests
São revistas pelo departamento de controlo de qualidade antes de serem enviadas para os programadores, se necessário.
Se uma versão contiver um commit de rede que tenha sido fundido, o departamento de controlo de qualidade deve poder automatizar os diferentes testes de conetividade (conforme descrito abaixo em configurações de chamadas). deve ser capaz de automatizar os diferentes testes de conetividade (conforme descrito abaixo nas configurações de chamadas)
Configurações de chamadas.
Esta é a lista de configurações de rede que precisam de ser testadas:
(IPv4 | IPv6) + (TURN | !TURN) + (STUN | !STUN) + (UPnP | !UPnP) para ambos os lados.
Se ambos os lados forem apenas IPv4 sem TURN/STUN/UPnP, a chamada deve ser apenas local.
O que é necessário fazer
Estabelecer um sistema na 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 a fundir para reduzir a regressão
Integrar sonarqube em cada cliente
Automatizar o teste do comportamento do Jami em termos de compatibilidade de rede