A premissa era que Brad precisava criar um sistema de cobrança de assinaturas que disparasse faturas periódicas e também atualizasse o registro do Cliente - usando C # e xUnit.net (estrutura de teste de Brad que ele criou com Jim Newkirk). Para muitos, isso parece simples. Para aqueles que implementaram tal coisa - é tudo menos.
O que eu realmente gostei desse episódio é que eu empurrei Brad apenas o suficiente para remover o “demo veneer” - eu dei a ele uma bola curva cerca de 30 minutos em que eu disse “Ah, sim… eu mencionei que também fazemos X ? - e ele teve que se ajustar.
Quando você tem uma confusão de testes que assumem uma coisa, então você precisa mudar para outra - é um pé no saco. Mas Brad lidou com isso incrivelmente bem - aproveitando a oportunidade para colocar mais estrutura em seu processo de teste, depois um por um “fez a transição” de seus testes antigos para a nova abordagem.
Trabalhamos a hora inteira em um único arquivo de código - e eu nunca tinha visto alguém fazer isso antes. Claro, eu criei uma classe ali dentro do código - mas assistir Brad girar classe após classe, renomear, excluir e reestruturar completamente seus testes ... foi muito, muito interessante.
Eles sempre dizem que o TDD é um "processo de design" - mas nunca o vi sendo usado de maneira realmente "design-y" - como um pintor pode jogar cor após cor em uma tela até parecer / sentir-se bem. E é exatamente assim que se sente olhando para ele.
Cerca de 15 minutos em Brad menciona que "deixo uma classe no arquivo de teste até que esteja pronta para ir a público" - o que significa que ele tem testes suficientes para justificar suas decisões de design. Um conceito que eu nunca tinha pensado antes - como usar o arquivo de teste como um "útero".
Ele “sentiu” o seu caminho através da criação do sistema de cobrança - conversando consigo mesmo o tempo todo e criando algo bastante interessante e bastante parecido com o que terminamos depois de quase três anos de existência.