Czy „oczywista implementacja” TDD oznacza najpierw kod, a potem test?

Mój przyjaciel i ja jesteśmy stosunkowo nowymi TDD i spieramy się o technikę „Oczywistej implementacji” (z „TDD według przykładu” Kent Beck). Mój przyjaciel mówi, że oznacza to, że jeśli implementacja jest oczywista, należy ją napisać - przed jakimkolwiek testem na to nowe zachowanie. I rzeczywiście książka mówi:

Jak wdrażasz proste operacje? Po prostu je zaimplementuj.

Również:

Czasami masz pewność, że wiesz, jak wykonać operację. Śmiało.

Myślę, że autor ma na myśli to, że powinieneś najpierw przetestować, a następnie „po prostu zaimplementować” - w przeciwieństwie do „Fake It („ Till You Make It) ”) i innych technik, które wymagają mniejszych kroków na etapie wdrażania. Również po tych cytatach autor mówi o uzyskiwaniu „czerwonych pasków” (nieudanych testów) podczas „Oczywistej implementacji” - w jaki sposób można uzyskać czerwony pasek bez testu ?.

Jednak nie mogłem znaleźć w książce żadnego cytatu, w którym „oczywiste” wciąż oznacza „najpierw test”.

Co myślisz? Czy powinniśmy najpierw przetestować, czy implementacja jest „oczywista” (oczywiście według TDD)? Czy znasz książkę lub post na blogu mówiący właśnie o tym?

Zgadzam się z twoją interpretacją - wciąż jest to Red Green Refactor, tylko z pominiętym bitem Refactor;)

Więc najpierw napisz test, a następnie zaimplementuj oczywiste rozwiązanie zamiast powoli budować projekt „najprostszego z możliwych”.

Czy znasz książkę lub post na blogu mówiący właśnie o tym?

Twierdziłbym, że książka Becka mówi właśnie to.

Mówi dalej

Jednak stosując tylko Oczywistą implementację, wymagasz doskonałości. Psychologicznie może to być druzgocący ruch. Co jeśli to, co piszesz, nie jest tak naprawdę najprostszą zmianą, która może sprawić, że test się powiedzie? Co jeśli twój partner pokaże Ci jeszcze prostszy? Jesteś porażką! Twój świat rozpada się wokół ciebie! Umierasz Zamarzasz.

Jak uzyskać pozytywny wynik testu, pisząc kod, jeśli nie istnieje on wcześniej?

Oczywiście nie ma tutaj twardych i szybkich reguł, w końcu były zwinne, więc możemy i powinniśmy się dostosowywać podczas iteracji :)

Częściowo będzie to zależeć od prostej operacji, a gdy ćwiczysz TDD coraz częściej, będziesz regularnie znajdować rzeczy, które źle przetestowałeś lub w rzeczywistości tak naprawdę nie testowałeś, to wszystko jest częścią krzywej uczenia się.

Nie zapominaj również, że TDD pozwala przetestować interfejs i implementację przed zatwierdzeniem go do kodu na żywo.

Być może wiesz, jak coś zaimplementować, ale jak często piszesz idealną klasę / metodę itp. Za pierwszym razem, bez żadnych drobnych poprawek po drodze lub przechodzenia przez kod raz lub dwa i sześć miesięcy później, kiedy zmieniasz coś, co możesz zrobić za pomocą więcej pewności i ponownie w piaskownicy testów.

Oczywiście testy nie oznaczają, że za pierwszym razem poprawnie piszesz kod, ale zmiany są napędzane przez test, a testy stają się pierwszym klientem kodu, a ponieważ testy są bardzo tanie i, co ważniejsze, nie powodują ryzyka zmiany masz więcej pewności siebie i wolności podczas rozwoju.

Jeśli naprawdę starasz się uzyskać dobry zasięg i wyższą jakość, na początku popełniaj błąd w następnej fazie testów, ponieważ w miarę trenowania TDD rozwiniesz swoje poczucie poziomu wymaganego zasięgu.

Dowiedziałem się, że w przypadku trywialnego kodu nie powinno być w ogóle żadnego nieprzystosowanego.

przykład: jeśli masz metodę getter / setter java, która odwzorowuje metodę na zmienną lokalną, najbardziej niestosowne dla tego byłoby nadmierne zabójstwo.

być może chodzi o to, co autor ma na myśli

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."