Sou relativamente novo no TDD e tenho problemas ao criar meu primeiro teste antes de qualquer código de implementação. Sem qualquer estrutura para o código de implementação, eu sou livre para escrever meu primeiro teste da forma que quiser, mas ele sempre parece estar manchado pela minha maneira Java / OO de pensar sobre o problema.
Por exemplo, no meu Github ConwaysGameOfLifeExemplo do primeiro teste que escrevi (rule1_zeroNeighbours), comecei criando um objeto GameOfLife que ainda não havia sido implementado; chamou um método set que não existia, um método step que não existia, um método get que não existia e, em seguida, usou uma declaração.
Os testes evoluíram à medida que escrevi mais testes e refatoramos, mas originalmente parecia algo assim:
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}Isso foi estranho, pois eu estava forçando o design da implementação com base em como eu havia decidido, nesta fase inicial, escrever este primeiro teste.
Da maneira que você entende TDD, está tudo bem? Parece que estou seguindo os princípios do TDD / XP, pois meus testes e implementação evoluíram ao longo do tempo com a refatoração. Portanto, se esse projeto inicial tivesse se mostrado inútil, estaria aberto a alterações, mas parece que estou forçando uma direção no solução iniciando dessa maneira.
De que outra forma as pessoas usam TDD? Eu poderia ter passado por mais iterações de refatoração começando com nenhum objeto GameOfLife, apenas primitivos e métodos estáticos, mas isso parece muito artificial.
