Arquivo Discussoes de Programacao e Tecnologia 
Olá pessoal
Na faculdade tivemos uma discurssão sobre a melhor definição de onde se encaixa os teste de unidade nos processos de Engenharia de Software.
Alguns acham que testes de unidade seria somente usado na construção do software
e não concordam em testes de unidade no processo de Testes do software
Já outros acham que devem ser nos dois processos…
E vocês… o que acham?
Testes nunca são demais. Claro que o exagero pode comprometer o tempo de desenvolvimento, mas eu diria que os testes unitários devem ser executados sempre que possível.
Frameworks como o JUnit permitem que testes unitários sejam escritos antes mesmo de começar a implementação. E DEVEM ser executados sempre que suas unidades sofrerem modificações.
Acho que vc esta fazendo a pergunta errada ao deixar implicito que o processo de construcao de software eh separado do processo de testes de software. Isso implica que vc nao esta fazendo os dois em paralelo e nos menores incrementos possiveis dentro de limites praticos.
Uma coisa é o processo de desenvolvimento acadêmico onde ninguem vai perder o emprego se uma imensa gambiarra for feita no coração do sistema.
Outra coisa é o mundo real onde o cliente quer uma coisa, o analista entende outra, o desenvolvedor implementa outra, o testador (quando existe) ganha muito mal para fazer um trabalho bem feito, e quando a coisa está “pronta” o cliente percebe que queria outra coisa (ok, tem exceções…).
Hoje em dia existem muitas visões diferente desse processo: tem quem defenda um modelo mais engessado pois só pensa em grana (vulgo algumas grandes consultorias), tem quem aplique uma metodologia de uma forma tão errada que faz algo pior que um Waterfall, tem quem defenda o Big Up Front Design (BUFD), mas também tem abordagens como XP, Scrum, Test-Driven Development , BDD, etc.
Seria interessante que vc lesse um pouco sobre tudo. Tem quem ache que teste unitário é desnecessário (ex: converse com programadores Cobol ou Natural). Tem quem ache que são o coração do desenvolvimento de software (ex: quem tem TDD no sangue).
A verdade é que atualmente vc tem N formas de fazer um software, seja ele um kernel de sistema operacional, um sisteminha pra uma padaria ou um sistema de gestão pra uma empresa que fatura muitos digitos de dinheiro por minuto. Não existe bala de prata.