TDD – Parte 04: Explorando os Mocks

No último post apresentei o uso de Mocks para conseguir testar as classes que ainda estão sendo desenvolvidas usando objetos das quais elas dependem sem ter que implementar tais objetos. Neste post, como era de se esperar, eu vou explorar melhor o uso do Rhino Mocks, mostrando as principais opções que ele dispõe no uso de Mocks.

TDD – Parte 03: Saiba como seu código se comporta

Você está efetuando os testes sobre sua camada de negócios, e alguns deles farão alterações no banco de dados, como a inclusão de um novo cliente, como mostrado no primeiro exemplo desta série, embora ele tenha sido muito tosco, conforme já admiti no post anterior. O que te incomoda são todos os vermelhos que irão surgir quando os testes tentarem fazer a inclusão de um cliente que já existe, e aí você vai lembrar que tem que limpar a base de testes sempre antes de executá-los.

E quando executar todos os testes, precisará verificar se os arquivos de Log foram devidamente criados no disco. Se os e-mails que o sistema deveria enviar foram devidamente enviados. E tantas outras evidências a colher em tantos lugares que não fazem parte do escopo de seus testes.

No fim das contas, tudo o que você precisa saber é se o seu software está se comportando como deveria. E você pode fazer isso executando um select na tabela de customers pra saber se o teste realmente inseriu alguém lá, ou pode simplesmente procurar algum meio de garantir que seu código faz isso sem que isso realmente ocorra.

Conheça o uso de Mocks.

TDD – Parte 2: 1, 2, 3… Testando

No último post eu dei uma breve introdução ao TDD. Muito breve, por sinal. Que só serviu mesmo para entendermos que é, acima de tudo, uma prática de design. Além de dar uma breve olhada em como fazer um teste.

Neste post, minha intenção é dar um pouco mais de sentido à prática do TDD fazendo alguns testes em cima de uma cesta de compras. Com isto, pretendo deixar um pouco mais claro a idéia de “Especificação Executável”.

TDD – Parte 1: É sobre Design.

TDD já não é exatamente uma modinha faz um bom tempo. Não se trata mais de 3 letrinhas pra colocar na sopa do currículo. Se trata de uma prática aprovada pela comunidade e seu uso já é bastante expressivo no mercado. De fato, o TDD já não precisa mais convencer quase ninguém a respeito da sua eficiência quando bem utilizado, e o problema está somente aí: fazer bom uso dele.

E para saber fazer bom uso dele é necessário entendermos uma coisa simples: TDD é de Test-Driven Design. Mas o que muita gente faz é focar no T de Test e esquecer do D de Design. Não se iludam: o T é o aspecto menos importante da sigla. O que realmente importa para nós aqui é o segundo D do TDD.