Não é novidade para ninguém que quanto mais testes automatizados sua aplicação possui, melhor é a confiança e segurança ao realizar alterações e refatorações no código.
Porém, não basta só escrever testes automatizados, mas sim, escrever de forma correta. Para isso, é muito importante entender os conceitos de testes automatizados. Por sorte, temos uma ilustração que mostra isso perfeitamente.
Onde eu quero chegar com isso? A grande parte dos testes automatizados devem ser compostos de testes unitários devido ao seu feedback rápido (conforme podemos visualizar na pirâmide de testes). Mas não somente testes unitários, podemos também mencionar os testes de UI e testes de estilização!
A grande questão é, o quanto devo validar a minha estilização? Devo cobrir 100% da estilização?
Como sempre, a resposta é...depende!
Conheço alguns dev's que costumam testar a aplicação de ponta a ponta, desde a estilização até os testes e2e (end-to-end). Já eu, não costumo testar a estilização das minhas aplicações, há não ser que faça parte de um comportamento funcional.
Como exemplo irei falar sobre um cenário que passei recentemente:
Nós que desenvolvemos aplicações de multiplataformas, devemos sempre nos preocupar se o design está conforme esperado. Principalmente quando falamos de Android e iOS.
Querendo ou não, sempre existe uma diferença de espaçamento ou design etc., entre as plataformas. E é aí que podemos utilizar os testes automatizados para validar esse comportamento de acordo com a plataforma especificada, que foi o meu caso.
Então, em vez de eu ficar validando visualmente conforme a plataforma especificada... Como um adotante do TDD (Test-Drive Development), comecei a escrever os testes de UI para estes comportamentos que variam conforme plataforma.
Assim, me assegurei que o que estava funcionando na plataforma Y, continuaria funcionando. E ao implementar para a plataforma X, não impactaria o que foi feito para a plataforma Y.
Portanto, entendo que os testes automatizados e em específico: testes unitários, testes de UI etc., devem validar o comportamento da funcionalidade. Se o estilo da aplicação muda conforme algum comportamento ou regra de negócio, seria interessante ter um teste automatizado para validar o mesmo.
Até a próxima.
Top comments (0)