TDD é uma atividade de design. O teste de unidade que você escreve serve basicamente para definir suas expectativas em relação ao código que você vai escrever. E, ao fazer isso, você pensa não só no nível da implementação do algoritmo, mas em um nível um pouco mais alto: no nível de design. TDD permite que você brinque e experimente diferentes possíveis designs, dando feedback rápido sobre o resultado obtido, até que você encontre o design ideal para aquela situação.

Ou seja, quando você faz TDD, você pensa exclusivamente em design e não em testes. É uma prática de suporte para design de software.

Mas… É claro que você precisa testar! Você não apaga os testes que você produziu usando TDD, óbvio. Mas muito provavelmente eles não testam todas as possibilidades possíveis. E é aí que outras técnicas entram em cena, e você pode encontrar muita informação sobre elas em [1][2].

Resumindo, use TDD quando você precisa trabalhar no design de determinada classe ou módulo. Quando você estiver satisfeito com design, é hora de testar! Aí você pode fazer test-first, test-last, ou que você preferir, mas teste de verdade!

[1] The Art of Software Testing – Myers
[2] Introdução ao Teste de Software – Maldonado, Delamaro, Jino

Se pensarmos em plataforma .NET, é impossível lembrar de cabeça todas as novidades apresentadas pela Microsoft nesses últimos tempos: WCF, WPF, Silverlight, Entity Framework, LINQ, ASP.NET MVC, etc, etc… É simplesmente impossível manter-se atualizado (com um bom nível de conhecimento, obviamente) em todas elas!

Pergunto novamente: Mas precisamos mesmo nos atualizar? Não, não precisamos. O principal objetivo de um desenvolvedor de software é entregar software para o cliente. Se hoje você desenvolve bons softwares, que agregam valor para seus clientes, e não faz uso das últimas novidades, não se culpe, você não está errado! Você não precisa re-programar todo seu sistema só porque dizem que o novo framework XPTO é bom! Programamos não para satisfazer nossos egos (afinal, quem não gosta de estar sempre atualizados, utilizando das melhores e mais modernas práticas?), mas sim para atender a necessidade do cliente. Se você já atende o seu cliente, não tem porquê mudar!

É a velha história do projeto perfeito e do projeto bom, onde todo projeto perfeito quer ser um projeto bom! O projeto perfeito nunca fica pronto, pois não dá tempo, seus desenvolvedores sempre querem o manter atualizado com as últimas novidades! Já o projeto bom, como o próprio nome diz, não é perfeito, não utiliza das últimas tecnologias de mercado, mas funciona, e o melhor, atende ao cliente!

Não estou dizendo que você não deva se atualizar. Claro que deve! Mas tudo isso deve ser feito de maneira cautelosa, estudada, e o mais importante: seu cliente não deve pagar por isso! Se algum framework promete ajudar no desenvolvimento e poupar futuras horas de desenvolvimento, faça testes, brinque, use e abuse dele, até ter certeza de que ele vai realmente lhe agregar valor, e que ele não vai ser um gargalo na hora do desenvolvimento.

Uma coisa que tem me chamado a atenção é o foco que as pessoas tem dado ao novo ASP.NET MVC, da Microsoft. As pessoas tem pulado de cabeça nessa novidade, sem nem pensar no impacto que isso vai ter sobre a equipe de desenvolvedores e sobre a qualidade do software que será desenvolvido. Será que os WebForms são tão ruins assim que merecem serem trocados de forma praticamente instantânea? Caso você ache que vale a pena trocar toda a experiência que sua equipe e investir horas de estudo nesse novo framework, pois o MVC vai lhe ajudar a escrever melhores softwares, siga em frente; caso contrário, não se sinta mal, continue usando WebForms e atendendo seu cliente da melhor maneira possível!

Não se esqueça da frase (da qual não me recordo o autor): Bons desenvolvedores DESENVOLVEM software. Ótimos desenvolvedores ENTREGAM software.

(Uma discussão do grupo .NET Architects me levou a escrever esse post)

Uma classe Carro, por exemplo, deve ser unica e exclusivamente responsável por realizar funções de um carro (como medir óleo, acender farol, etc). A classe Carro não deve ser responsável por saber se lavar (essa é uma responsabilidade que poderia ser entregue a uma classe LavaRapido, por exemplo).

Conversando hoje com o Murilo Amêndola, discutimos sobre como saber quais as responsabilidades de uma classe. Concordamos que não é uma tarefa trivial e que depende de muita experiência para que todas suas classes tenham um alto nível de coesão. Lendo hoje um trecho do livro citado acima, encontrei um algoritmo muito interessante para saber se determinada responsabilidade deve ou não pertencer a determinada classe. Vou reproduzí-lo aqui:

Voltando ao exemplo da classe Carro:

Repare que faz todo sentido o carro medir óleo sozinho, enquanto não faz sentido nenhum o carro se dirigir sozinho (esse método deveria estar em uma classe Motorista), ou se lavar sozinho (deveria ser responsabilidade da classe LavaRapido)!

O método liga e desliga não fazem taaanto sentido (afinal, um carro não se liga sozinho), mas nesse caso, não vejo outra alternativa (é o carro que sabe como se ligar!). Isso mostra que a regra acima é apenas uma diretriz, e por isso você deve usar de bom senso e de sua experiência.

O interessante é que você pode adaptar essa regra até para métodos que recebem parâmetros. Se você tiver um método troca(peça), você escreve a seguinte sentença: O carro troca [uma]  peça sozinho. No caso, também não faz muito sentido, você poderia ter uma classe Mecânico, com o método troca(peça, carro).

Enfim, é uma análise interesse, não acham?

(Exemplo retirado do livro Use a Cabeça: Desenvolvimento de Softwares, capítulo 5.)