Sono abbastanza nuovo in TDD e ho problemi a creare il mio primo test prima di qualsiasi codice di implementazione. Senza alcun framework per il codice di implementazione, sono libero di scrivere il mio primo test come voglio, ma sembra sempre uscito contaminato dal mio modo di pensare Java / OO al problema.
Ad esempio nel mio Github ConwaysGameOfLifeExample il primo test che ho scritto (rule1_zeroNeighbours) ho iniziato creando un oggetto GameOfLife che non era stato ancora implementato; chiamato un metodo set che non esisteva, un metodo step che non esisteva, un metodo get che non esisteva e quindi usato un'asserzione.
I test si sono evoluti quando ho scritto più test e refactored, ma originariamente sembrava qualcosa del genere:
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}Mi è sembrato strano mentre stavo forzando la progettazione dell'implementazione in base a come avevo deciso in questa fase iniziale di scrivere questo primo test.
Nel modo in cui capisci TDD, va bene? Mi sembra di seguire i principi TDD / XP in quanto i miei test e l'implementazione si sono evoluti nel tempo con il refactoring, quindi se questo progetto iniziale si fosse rivelato inutile sarebbe stato aperto al cambiamento, ma mi sembra di forzare una direzione sul soluzione iniziando in questo modo.
In che altro modo le persone usano TDD? Avrei potuto attraversare una maggiore iterazione del refactoring iniziando senza alcun oggetto GameOfLife, solo primitivi e metodi statici ma sembra troppo forzato.
