Se você se preocupa com qualidade para desenvolvimento de software, sugiro que você leia também meu outro artigo da edição deste mês na .Net Magazine (edição 53), que fala sobre testes unitários utilizando mocks e stubs.

Li a algum tempo em algum blog uma definição de legado. Pelo que eu me lembro:

1) Se você não documentou, é legado.
2) Se você não criou testes unitários, é legado.
3) Se outra pessoa não consegue ler o código, ou ele parece uma macarronada, de tão embarassado, é legado.

Não interessa se você escreveu o código hoje de manhã. Se você não criou testes unitários ele é automaticamente código legado. Então, para ajudar a diminuir a quantidade de código legado no mundo, eu quis escrever este artigo, e os próximos que virão (é uma pequena série, a terceira vai ser focada em testes com ASP.Net MVC). Ele vai te mostrar como escrever testes verdadeiramente unitários, vai diferenciar testes unitários de testes integrados, e vai te ensinar a criar uma aplicação mais testável, ou seja, que te permite testar, por exemplo, um componente de acesso a dados, sem a base de dados.

Garanto que, se você passar a testar seu código, a criar um teste unitário logo após criar uma função de negócio, a qualidade do que você desenvolve vai melhorar muito. E se você já testa, mas não conhece os objetos de mock, vai ganhar muito, porque a idéia do mocking como um todo é sensacional.

Me digam o que acharam. Vão passar a testar? Vale a pena?