Soy bastante nuevo en TDD y tengo problemas al crear mi primera prueba cuando se trata de cualquier código de implementación. Sin ningún marco para el código de implementación, soy libre de escribir mi primera prueba como quiera, pero siempre parece estar contaminada por mi forma de pensar Java / OO sobre el problema.
Por ejemplo, en mi Github ConwaysGameOfLifeExample, la primera prueba que escribí (rule1_zeroNeighbours) comencé creando un objeto GameOfLife que aún no se había implementado; llamó un método de conjunto que no existía, un método de paso que no existía, un método de obtención que no existía, y luego usó una afirmación.
Las pruebas evolucionaron a medida que escribía más pruebas y las refactorizaba, pero originalmente se parecía a esto:
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}Esto se sintió extraño ya que estaba forzando el diseño de la implementación en función de cómo había decidido en esta etapa temprana escribir esta primera prueba.
En la forma en que entiendes TDD, ¿está bien? Parece que sigo los principios de TDD / XP en el sentido de que mis pruebas e implementación evolucionaron con el tiempo con la refactorización, por lo que si este diseño inicial hubiera resultado inútil, habría estado abierto a cambios, pero parece que estoy forzando una dirección sobre el solución comenzando de esta manera.
¿De qué otra forma las personas usan TDD? Podría haber pasado por más iteraciones de refactorización comenzando sin ningún objeto GameOfLife, solo primitivos y métodos estáticos, pero eso parece demasiado artificial.
