Dúvida: Boas práticas em testes automatizados · NathanFirmo

Preciso de ajuda

Hoje eu queria ouvir um pouco da opnião de programadores mais experientes na questão de testes automatizados. Comecei a escrever alguns testes na empresa em que trabalho. Praticamente não tem testes ainda, só os meus, mas eu quero fazer da forma correta.

Nossa stack

Recentemente eu e um colega refatoramos parte do backend do projeto. Estamos migrando para uma arquitetura de microsserviços usando o NX. As APIs, que no momento são meu foco em questão de testes, foram feitas usando Nest.js.

Como estou indo no momento

Eu estou usando a integração nativa do NestJS com Jest para testes e tenho gostado. A minha dúvida é se estou usando o nível de isolamento adequado. Basicamente os testes que escrevi, testam integrações externas e também CRUDS, sem nenhum mock. Escrevi de maneira que os testes que dependam do banco possam funcionar sempre, considerando que há um seed do projeto. Além disso eu procurei criar os testes na ordem CRIAR, BUSCAR, ATUALIZAR e DELETAR. Dessa forma, sempre que possível uma nova instância é criada antes de tudo e depois eu testo se o retorno está de acordo com o esperado. Não sei se fiz certo, mas busquei que os testes fossem tão desacoplados o quanto possível, mas sem muitos mocks. Pois eu não queria ter a falsa impressão do código estar Ok, mas na verdade eu ter escrito um teste falho.

Mais uma vez, obrigado comunidade do TabNews, vocês são incríveis! 😄

Nathan, eu acabei atropelando essa publicação, não tinha visto ela!

E a sua pergunta é sensacional e uma briga eterna entre quem gosta de escrever testes unitários, versus testes de integração, versus testes e2e e todos os tradeoffs envolvidos.

No TabNews estamos por enquanto apenas com testes de integração e pessoalmente não vejo necessidade escrevermos testes unitários, pois o princípio que adotei foi o mesmo que o seu: me importo em como foi implementado menos do que se está de fato funcionando na camada externa da API. Então funcionar para mim é mais importante do que tudo, o resto a gente refatora, e é aí que eu vejo os testes unitários brigando muito com você. Eu digo isso porque a interface de uma API muda numa velocidade muito menor do que a interface das unidades que você compõe o sistema, e esse "miolo" do sistema vai precisar ser refatorado a todo momento.

Então numa bateria de testes de integração, você pode refatorar o que quiser dentro do miolo da aplicação que nenhum teste deverá quebrar por conta disso. Isso não necessariamente se aplica aos testes contra as unidades que tiveram sua interface pública alterada/refatorada.