Jestem dość nowy w TDD i mam problemy z tworzeniem pierwszego testu, który pojawia się przed jakimkolwiek kodem implementacyjnym. Bez żadnych ram do kodu implementacyjnego mogę napisać mój pierwszy test, jakkolwiek chcę, ale zawsze wydaje się, że jest on skażony moim sposobem myślenia o problemie w Javie / OO.
Na przykład w moim Github ConwaysGameOfLifePrzykład pierwszy test, który napisałem (rule1_zeroNeighbours) Zacząłem od stworzenia obiektu GameOfLife, który nie został jeszcze zaimplementowany; nazywał metodę set, która nie istniała, metodę step, która nie istniała, metodę get, która nie istniała, a następnie użyła asert.
Testy ewoluowały, gdy napisałem więcej testów i zostały przebudowane, ale początkowo wyglądało to mniej więcej tak:
@Test
public void rule1_zeroNeighbours()
{
GameOfLife gameOfLife = new GameOfLife();
gameOfLife.set(1, 1, true);
gameOfLife.step();
assertEquals(false, gameOfLife.get(1, 1));
}To wydawało mi się dziwne, kiedy wymuszałem projektowanie implementacji w oparciu o to, jak postanowiłem na tym wczesnym etapie napisać pierwszy test.
W jaki sposób rozumiesz TDD, czy to w porządku? Wydaje mi się, że przestrzegam zasad TDD / XP, ponieważ moje testy i implementacja ewoluowały wraz z refaktoryzacją, więc jeśli ten początkowy projekt okazałby się bezużyteczny, byłby otwarty na zmiany, ale wydaje mi się, że wymuszam kierunek na rozwiązanie, zaczynając w ten sposób.
Jak jeszcze ludzie używają TDD? Mógłbym przejść przez kolejne iteracje refaktoryzacji, zaczynając od braku obiektu GameOfLife, tylko prymitywów i metod statycznych, ale wydaje się to zbyt wymyślone.
