Você já deve ter lido um livro no TDD, um par de artigos dos gurus e, talvez, até mesmo feito a calculadora Kata várias vezes. Agora é hora de aplicar o seu conhecimento para um projeto real, que você está começando hoje. Você provavelmente fica encarando a solução, tentando descobrir por onde começar. “Criar uma instância do sistema em teste”. Qual sistema? “Disfarçar, ou esboçar as dependências”. Quais dependências? Essas perguntas te parecem familiar?

Deixa que eu te ajudo!

Agora também estou olhando para a (quase) solução vazia. Vou tentar documentar o que penso e faço, e talvez você considere útil. No entanto, lembre-se de que não é a única forma de fazer isso, não é provavelmente a melhor maneira e, inclusive, pode ser um mau caminho. Mas funciona para mim e pode funcionar para você; então, se você não tiver uma solução melhor, tente essa.

Conheça Chpokk, um editor de código .Net online

Veja o Chpokk como uma alternativa leve para o Visual Studio e que é integrada com controle de fonte, além de alguns presentinhos, como suporte à refatoração e que roda os testes etc. Decidi que hoje seria um grande dia para desenvolver a primeira característica que pode ser realmente útil.

O que eu quero dos meus testes

Existem vários requisitos importantes que me ajudarão bastante a escrever o meu primeiro teste. Quero produzir alguns valores de negócio o mais rápido possível e não tenho tempo para todos esses brinquedos engraçados do AbstractFactoryFactory. Se isso significa criar um método estático grande, tudo bem. Irei refazer mais tarde. Mas quando eu refatorá-lo, precisarei dele para estar acobertado por um teste. Então, o meu primeiro teste deve ser sobre a primeira coisa útil que eu queira implementar no meu sistema.

Não quero que meus testes sejam frágeis. Eu não sei o que o meu UI vai ser e eu não conheço a minha API ainda. Mas mudar a interface do usuário pode quebrar facilmente muitos testes que dependem dela, enquanto o código do lado do servidor pode ser facilmente reformulado em sincronia com os testes. Não só o UI, mas qualquer coisa “pegajosa” deve ser mantida fora. Por exemplo, eu não quero codificar a pasta em que eu vou manter os arquivos do código do usuário.

Esse tipo de exigência contradiz a anterior, que sugeria que o meu primeiro teste deveria cobrir tudo. Mas enquanto a primeira exigência é mais como um desejo bom que me faria feliz agora, a segunda me salvaria da dor permanente mais tarde, uma vez que testes robustos são o que me fazem dormir bem à noite.

Os testes não deveriam utilizar qualquer conhecimento de fora, mas isso é mais bem explicado com um exemplo. Diga “eu vou clonar um repositório existente de GitHub”. Então, vou verificar se um determinado arquivo existe em nível local. O conhecimento sobre o nome do arquivo que deveria estar lá não é uma parte do teste. Este pode ser um problema, já que mais tarde, ao olhar para esse teste, não saberei por que ele espera esse arquivo em particular. Além disso, eu poderia renomear esse arquivo mais tarde, a fim de usá-lo em um teste diferente.

Como posso corrigir isso? Adicionando esse arquivo ao repositório remoto como parte do teste. Isso dificulta a minha vida, mas pelo menos posso olhar para o teste e entender por que o arquivo deve estar lá. Além disso, o meu teste é responsável pela criação de seu ambiente. O ideal seria criá-lo em um repositório remoto, mas isso é muito raro. Na verdade, eu poderia até mesmo gerenciar sem adicionar esse arquivo, mas o conteúdo do repositório é algo mutante, enquanto os próprios repositórios tendem a ficar mais tempo.

Chega de filosofia, mostre-me o código já!

Não tão rápido, meu amigo! Espere a próxima parte, onde estou deduzindo os requisitos para a primeira iteração e escrevendo testes para ela.

 ***

Artigo original disponível em: http://ivonna.biz/blog/2012/3/11/writing-the-first-test-for-a-real-system.aspx