Sim, a mensagem é essa: Testem até não poderem mais, caso isso aconteça, peça para outra pessoa continuar os testes. Pode ser um exagero, mas não é. Quanto maior for o tempo de teste maior será a probabilidade de não ocorrer problemas, conseqüentemente, maior será a sua credibilidade sobre o seu serviço. Sim desenvolvedores também escrevem testes;
A escrita de testes é tão importante quanto a escrita de código fonte. Bom, isso é facilmente justificado através das características de nosso cérebro. Vou explicar: A partir do momento que nos deparamos com situações que envolvem repetição, como passar por uma mesma rua várias vezes, seu cérebro entra em um estado de abstração dessas informações. Isso nos dá a sensação de que o tempo está passando rápido. Com isso é normal ter comentários como: “Essa semana passou rápido” ou “Nossa, já é Dezembro, como o ano passou rápido”.
Bom, vocês devem está se perguntando onde eu quero chegar com essa baboseira toda. Isso é simples. Compreender os testes! Quando estamos desenvolvendo é normal que não nos preocupemos com testes, não devíamos, mas é o que acontece. Nesse processo, estamos preocupados em desenvolver funcionalidades, criar classes, escrever consultas e poucos se preocupam com teste.
Os testes são escritos tardiamente após termos passado várias vezes pelo código que contem a funcionalidade a ser testado. Com isso, entra em cena o fenômeno que citei no início do texto, colaborando com a analise defeituosa do problema e ao mesmo tempo com a ausência da escrita de códigos de testes.
Deixar um projeto sem código de testes é um suicídio. Futuramente, caso exista necessidade de fazer alguma manutenção nos fontes, não será possível saber se a modificação efetuada irá impactar em alguma funcionalidade contida na aplicação, pois não há maneira de rodar os testes para verificar se o código inserido afeta, diretamente ou indiretamente, as outras funcionalidades implementadas.
Afirmo isso porque já trabalhei em projetos que necessitavam de freqüentes testes. Sempre que concluíamos uma funcionalidade, construíamos inúmeros códigos de testes unitários para validar os métodos que compunham o escopo da funcionalidade desenvolvida. Posteriormente adicionávamos tudo isso no start de testes para testar tudo de uma vez. Após isso, todos achavam mais confortáveis em desenvolver novas funcionalidades, já que sempre que fosse possível, rodavam a bateria de testes para verificar se houve algum impactos com as funcionalidades que já foram desenvolvidas.
Escrever testes unitários deveria ser tarefa de qualquer desenvolvedor que vise a qualidade de seu trabalho, não apenas por motivos promocionais, mais principalmente pela equipe que está alocada ao projeto. Quanto mais se testa um produto, menores são as chances de erros em projetos. Isso não acontece apenas em desenvolvimento de software, mas também em outras áreas.
Hoje em dia, é possível contar com a colaboração de inúmeras técnicas e frameworks desenvolvidos para essa finalidade sejam para cada tipo de teste. Entre os mais utilizados estão os frameworks voltados para testes unitários como o JUnit e TestNG. Não irei falar sobre nenhum deles e nem afirmar qual o melhor, talvez em próximo post. A princípio, quero mostrar a vocês que existem diversos elementos que facilitam a escrita de testes, principalmente testes unitários.
As metodologias ágeis contribuem massivamente para que testes sejam escritos e executados de forma automática, no momento da integração contínua ou até mesmo antes da geração do build. As metodologias ágeis incentivam o uso de ferramentas de execução de testes automáticos através da integração contínua, pois através dela a aplicação será testada exaustiva vezes e comparada com diversos builds existentes no repositório. Essa é uma excelente abordagem, já que os testes não são executados pelo desenvolvedor e sim pelo servidor de integração contínua.
Existem vários tipos de testes e diversas técnicas que são aplicadas. Aplicá-las em projetos reais sempre será uma excelente alternativa. Porem, a obrigatoriedade de escrever testes unitários fica mesmo com o desenvolvedor.
