Ich bin ziemlich neu in TDD und ich habe Probleme, wenn ich meinen ersten Test erstelle, wenn er vor dem Implementierungscode steht. Ohne irgendeinen Rahmen für den Implementierungscode kann ich meinen ersten Test schreiben, wie ich will, aber er scheint immer von meiner Java / OO-Denkweise über das Problem befallen zu sein.
Zum Beispiel habe ich in meinem Github ConwaysGameOfLifeExample den ersten Test geschrieben (rule1_zeroNeighbours), indem ich ein GameOfLife-Objekt erstellt habe, das noch nicht implementiert wurde. bezeichnet eine nicht existierende Set-Methode, eine nicht existierende Step-Methode, eine nicht existierende Get-Methode und verwendet dann eine Zusicherung.
Die Tests entwickelten sich, als ich mehr Tests schrieb und überarbeitete, aber ursprünglich sah es ungefähr so aus:
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}Dies fühlte sich seltsam an, als ich das Design der Implementierung erzwang, basierend darauf, wie ich mich zu diesem frühen Zeitpunkt entschlossen hatte, diesen ersten Test zu schreiben.
Wie Sie TDD verstehen, ist das in Ordnung? Ich scheine den TDD / XP-Grundsätzen zu folgen, da sich meine Tests und Implementierung im Laufe der Zeit mit dem Refactoring weiterentwickelt haben. Wenn sich dieses anfängliche Design als unbrauchbar erwiesen hätte, wäre es offen für Änderungen gewesen, aber es scheint, als würde ich eine Richtung auf dem Weg erzwingen Lösung, indem Sie auf diese Weise starten.
Wie nutzen andere Menschen TDD? Ich hätte mehr überarbeiten können, indem ich ohne GameOfLife-Objekt angefangen hätte, nur mit primitiven und statischen Methoden, aber das scheint mir zu kompliziert.
