Sono abbastanza nuovo per TDD e ho problemi durante la creazione del mio primo test quando viene prima di qualsiasi codice di implementazione. Senza alcuna struttura del codice di implementazione, sono libero di scrivere il mio primo test, ma lo voglio sempre, ma sembra sempre influenzato dal mio modo di pensare Java / OO sul problema.
Ad esempio nel mio Github ConwaysGameOfLifeExample il primo test che ho scritto (rule1_zeroNeighbours) ho iniziato creando un oggetto GameOfLife che non aveva è stato ancora implementato; chiamato un metodo set che non esisteva, un metodo step che non esisteva, un metodo get che non esisteva e quindi utilizzava un assert.
I test si sono evoluti nel momento in cui ho scritto più test e refactored, ma in origine era simile a questo:
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}
Questo è strano visto che stavo forzando la progettazione dell'attuazione in base a come avevo deciso in questa fase iniziale di scrivere questo primo test.
Nel modo in cui capisci che TDD è ok? Mi sembra di seguire i principi TDD / XP in quanto i miei test e la mia implementazione si sono evoluti nel tempo con il refactoring, e quindi se questo progetto iniziale si fosse dimostrato inutile sarebbe stato aperto a cambiare, ma mi sembra di forzare una direzione sul soluzione iniziando in questo modo.
In quale altro modo le persone usano TDD? Avrei potuto passare attraverso più iterazioni di refactoring iniziando senza oggetti GameOfLife, solo primitive e metodi statici, ma sembra troppo inventato.
