TDD oczami twórcy

Okładaka: TDD. Sztuka tworzenia dobrego kodu
Tytuł: TDD. Sztuka tworzenia dobrego kodu
Autor: Kent Beck
Rok: 2004 (PL 2014)
ISBN: 978-832-4685-03-5

Drugą książką, którą chciałbym wam zaprezentować z okazji długiego weekendu, jest książka Kenta Becka o TDD. Autor jest twórcą tej techniki, co powoduje, że ciężko jest dyskutować z zawartością książki w kontekście „czy tak powinno wyglądać TDD” (czy ma sens to inna sprawa). Książka ma trzy części. Pierwsza poświęcona jest przykładowi praktycznego, ortodoksyjnego zastosowania TDD w implementacji obliczeń finansowych. Druga poświęcona jest architekturze xUnit, a trzecia wzorcom obecnym w TDD.

Przy czym warto zacząć lekturę od końca, tzn. od części trzeciej. Dzięki temu osoby, które nie miały do czynienia z TDD, nie zrażą się przykładem, a doświadczeni programiści przejdą od razu do „mięska”. Część pierwsza jest wkurzająca (serio), bo czytając ją, można dojść do wniosku, że TDD jest strasznie czasochłonne. To oczywiście złudzenie, ponieważ te 90 stron opisuje jakieś 2 godziny pracy. W efekcie doświadczamy irytacji. Druga część jest dla pasjonatów, którzy chcą wiedzieć więcej i najlepiej z pierwszej ręki.

Czy warto? Tak. Czy polską wersję? Nie, choć tłumaczenie jest lepsze niż w przypadku Software Craftmanship. Dla kogo? Dla każdego i na każdym etapie kariery. To chyba najlepsza charakterystyka tej książki.

5 myśli na temat “TDD oczami twórcy

  1. Mam wzorce implementacyjne tego autora i muszę powiedzieć, że czyta się to najlepiej do poduszki… Jeszcze żadna książka nie potrafiła mnie tak znudzić. Wiele stron o tym jak powinno się nazywać klasy a jak nie, przy czym są to wszystko opinie autora. Z opiniami nie zawsze trzeba się zgadzać.

    A jak jest z TDD? Czy Kent też przymula i zanudza?

  2. Jeżeli założymy, że „Wzorce implementacyjne” są nudne, to TDD nie odbiega od normy. Z drugiej strony ta „nuda” jest bardzo ważnym elementem warsztatu.

  3. Mam tę książkę, i również mogę polecić. Od niej zacząłem pisać testy na razie trochę nieśmiało ale w końcu się przełamałem 😉 Mam też do ciebie koziołku pytanie odnośnie pisania testów: piszę restowego klienta do pewnej niepublicznej usługi, przy użyciu jax-rs i na razie mam tak, że testy wywołują restowe API tak jak byśmy to robili już w programie. Wiem, że to nie jest dobre rozwiązanie- bo gdy nie będzie dostępu do internetu lub padnie im usługa na serwerze to wszystkie testy zarumienią się na czerwono. Więc musiałbym sobie te dane „zamokować” i zrobić jakieś fejki. Ok ale z drugiej strony jest to usługa pisana przez zewnętrzną firmę dla naszej „kochanej” administracji publicznej i dopiero ona nam to udostępnia. Więc testy mam po to, żeby sprawdzić czy oni czegoś nie zmienili u siebie bez powiadomienia innych :-] Wiem to z doświadczenia- mieliśmy taką sytuację z innym webservice (soap) o podobnej funkcjonalności pisany przez tę samą firmę.
    Jak sądzisz- pisać w takiej sytuacji drugi zestaw testów, tyle że z wartościami mokowanymi? Może jest jakiś sprytniejszy sposób?
    Trochę tak jakby musieli wydawać miliony z przetargu na konto na twitterze do powiadomień :-]

  4. @Marcin, tu masz do czynienia z „biblioteką”, którą można sobie spokojnie zamockować. Moim zdaniem możecie zrobić dwie rzeczy. Po pierwsze wprowadzić pomiędzy tamtą usługą, a swoją aplikacją dodatkowego „pośrednika” na przykład synapsę → http://synapse.apache.org/. W ten sposób będziesz trochę odporniejszy na zmiany API usługi. Wywali się synapsa, a nie aplikacja. Jeżeli zmiana w API nie jest z waszego punktu widzenia istotna, to można ją też zawsze odfiltrować na synapsie. Po drugie rozdziel testy integracyjne, te wołające usługę, od jednostkowych, tych korzystających z odpowiedzi. W ten sposób w pierwszych będziesz mógł podstawić spreparowane dane za pomocą synapsy, która na konkretne żądania odpowie konkretnym plikiem, a w drugich będziesz mógł użyć mocków, albo obiektów zwracających konkretne wartości. Rzuć okiem na https://koziolekweb.pl/2016/05/07/idiomy-z-java-8-iii/

    Jeszcze innym podejściem jest użycie wiremocka http://wiremock.org/ by zbudować cały punkt dostępowy.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax