Fala pessoal beleza! Ao implementar testes unitários, os bons desenvolvedores tentam, tanto quanto possível, seguir o princípio FIRST. Na real, FIRST é uma combinação de vários princípios, e neste post aprenderemos sobre esses princípios. A primeira letra do princípio FIRST significa FAST ou em português rápido. Os testes unitários são pequenos pedaços de código que executam uma tarefa específica. Como os testes unitários são pequenos e, ao contrário dos testes de integração, não se comunicam com servidores ou bancos de dados remotos, eles são executados muito rapidamente.
A próxima letra no princípio FIRST significa INDEPENDENT o que claro em português é independente. Idealmente, os testes unitários devem ser independentes uns dos outros. Um teste unitário não deve depender do resultado produzido por outros testes unitários. Na verdade, por padrão, os testes unitários são executados em uma ordem aleatória. Isso não é óbvio e não sabemos realmente qual teste unitário será executado primeiro e qual teste unitário será executado em segundo lugar. O código que estivermos testando ou o system under test também deve ser isolado de suas dependências. E isso é para garantir que o bug em uma dependência não influencie um teste unitário. Portanto, as dependências geralmente são mockadas ou usamos stubs com dados predefinidos. E desta forma os testes unitários podem testar o system under test de forma isolada de suas dependências e produzir um resultado muito preciso.
A próxima letra no princípio FIRST significa REPEATABLE ou em português repetível. Nós precisamos que o processo seja repetível. E se executarmos os mesmos testes unitários várias vezes, eles devem produzir o mesmo resultado. Se precisarmos que o teste seja executado em um computador diferente, ele também deve produzir o mesmo resultado. É por isso que precisamos de testes independentes do ambiente e de outros testes unitários. Os parâmetros que o método e o teste requerem são geralmente predefinidos e codificados, e se o método que estivermos testando precisar ser testado com parâmetros válidos e inválidos, você criará dois, três ou mais testes unitários diferentes. Cada teste unitário testará o método com seu próprio conjunto de parâmetros predefinidos. E desta forma precisamos que o teste se torne repetível. E se o executarmos várias vezes em ambientes diferentes em um computador diferente ou em um sistema operacional diferente, ele ainda produzirá o mesmo resultado toda vez que o executarmos.
A próxima letra significa self-validating ou autovalidação. E isso significa que, para saber se o teste passou ou não o desenvolvedor não deve fazer nenhuma verificação manual adicional. Após a conclusão do teste ele mesmo precisará auto validar o resultado. O method under test por si mesmo decidirá se o teste unitário está passando ou falhando. Depois que o teste unitário for concluído, o resultado deverá ficar claro.
Por fim a última letra representa Thorough & Timely que em português significa dizer que, ao testar um método, devemos considerar tanto o caminho feliz quanto o cenário negativo. E isso significa que, na maioria das vezes, criamos vários testes unitários para testar um método que aceita diversos tipos de parâmetros. Um teste unitário testará seu método com parâmetros válidos e outros testes unitários testarão o método com parâmetros inválidos. E se houver um intervalo como valor mínimo e máximo, devemos criar testes unitários adicionais para testar valores mínimos e máximos também.
Além disso é melhor criar os testes unitários no momento em que estivermos trabalhando na funcionalidade. Dessa forma, temos mais confiança de que as regras de negócios funcionam conforme o esperado e há menos chances de introduzirmos um bug e ele acabar entrando em produção. Portanto, antes de disponibilizarmos nosso código em produção, ele deve ser coberto por testes unitários. Bom pessoal por esse post é isso no próximo post falaremos sobre como testar código em isolamento!
Treinamentos relacionados com este post
