Testes automatizados já virou uma prática obrigatória quando se busca qualidade no desenvolvimento de sistemas, tanto que, metodologias ágeis tem por padrão, testes automatizados nos seus processos, sendo que, para ter entregas incrementais e continua de software, você precisa de testes para garantir a funcionalidade do que esta sendo entregue.

Mas garantir que o software entregue esta funcionando é apenas uma das diversas vantagens que se obtêm. Quando escrevemos testes, o código de produção (código do sistema, com exceção dos testes), tende a ter mais qualidade e evidenciar as más práticas.

Testes unitarios, por exemplo, nos força a escrever código mais desacoplado, por ser mais testável. Então, durante a escrita dos testes, percebemos com maior facilidade os trechos de código, que deveriam ser um serviço ou estar em outra camada da aplicação.

Duplicidade nos testes. Quando a suíte de testes vai crescendo, e percebemos que algum trecho de código esta sendo testado mais uma vez, é um forte indício de que algum trecho do código de produção esta duplicado, e seria uma boa ideia centralizar isso num lugar só, para não violar o SRP.

Testes de interface com selenium, ou outro framework, ajuda a simular a jornada do usuário na aplicação. Caso os testes fiquem muito extensos e complexos, provavelmente a aplicação tambem esta complexa para o usuário. Se isso acontecer, vale a pena repensar se a interface esta com a usabilidade adequada.

Testes de controller. Esses testes devem ser bem simples, sendo que o controller, só deve receber as requisições do usuário, e responder com o model e view respectivo, e caso necessário, chamar um serviço ou provedor que tenha alguma lógica. Portanto, se o teste estiver grande ou complexo, testando lógica de negócio, ou algo semelhante, provavelmente o controller esta com mais responsabilidades do que deveria, e uma refatoração seria necessária, para manter a qualidade do código.

É comum testes sevirem como o nivel mais granular de documentação do software, isso porque testes bem escritos são diretos e claros, e deixam explicito no nome o seu propósito. Por exemplo: se o nome do teste for “IShouldCantCreateAUserWithoutEmail”, fica claro e documentado, o que é esperado do código de produção, nesse caso, não poder criar um usuário sem email. E esse teste não vai ficar obsoleto como documentações em pdf ou semelhantes, por acompanhar a evolução do software. Sendo que todos os testes são executados ao menos uma vez antes de cada release.

Testes além de garantir que o software esta funcionando corretamente, também aumenta a qualidade, evidencia as más práticas, facilita a detecção de bugs, redundâncias e problemas com o código de produção, além de servir como uma documentação que vai ajudar os desenvolvedores. Portanto, se qualidade é importante no seu projeto, e acredito que é, escreva testes automatizados.