The Tests
E chegamos na minha parte favorita, os tests!
A “Api Doc - SDK” tem como objetivo principal abstrair as regras do API Rest do projeto principal e encapsulá-las.
Os métodos realizam, em sua maioria, chamadas de banco de dados, usando a tecnologia “Knex” e todos são exportados individualmente, sendo assim, a menor unidade da SDK pode ser testada, permitindo a implementação dos tests unitários.
Pensando em “CI”, passei a executar os tests após os push no projeto “Git”.
Running Tests And Continuous Integration
Após o push para o respitório Git, a integração continua entra em ação, realizando o script de tests já pré-definido para o projetos, seguindo a seguinte ordem:
- Instalação
- Build
- Tests
The Coverage
Após finalizado o test, é gerado um relátorio que informa qual é a cobertura do código, a “coverage”.
Basicamente, esse relatório explica quais regiões do código os tests estão “fracos” ou “fortes”, permitindo assim, que o “Tester” saiba exatamente quais métodos estão sendo negligênciadas, permitindo a criação de tests para aquela determinada região.
Um outro ponto importante dos testes unitários, é o fato de que para se obter uma boa cobertura, se faz necssário não somente testar os resultados das métodos, mas também provacar exceções.
Ou seja, uma boa taxa de cobertura não consiste somente em testar o resultado de uma função, mas também testar o erro, dessa forma, um test baseado somente em resultados nunca atingirá 100% de cobertura.
The Badge
É comum entrar em repositórios e ver vários badges, basicamente eles podem estar conectados a relatórios, como o “action github” ou outros tipos de serviços.
No caso do repositório “Api Doc - JS SDK”, eu estou utilizando o badge do Travis, que permite uma visualização rápida da última integração realizada e também a do Codecov, que a visualização prévia do resultado do Coverage
