[kot1401]

Bawię się w Test-Driven Development.

Załóżmy, że chcę stworzyć nowy bardzo rozbudowany feature w moim projekcie.

Feature będzie składał się z kilku/kilkunastu klas + jednej głównej (np. SomethingService), która będzie operowała na obiektach z tych kilkunastu klas.

W takim przypadku mam najpierw stworzyć testy dla tej głównej klasy, czy raczej zacząc od testowania tych mniejszych i dopiero na końcu je zmockować i stworzyć testy dla SomethingService?

#programowanie #php #testdrivendevelopment #phpunit #testyjednostkowe #laravel

[S.....s]

W takim przypadku mam najpierw stworzyć testy dla tej głównej klasy, czy raczej zacząc od testowania tych mniejszych i dopiero na końcu je zmockować i stworzyć testy dla SomethingService?

@kot1401: co to za TDD skoro już klasy masz, a dopiero teraz myślisz jak rozpisać testy ( ͡° ͜ʖ ͡°)

[kot1401]

@Skarfejs: klasy mam tylko w wyobraźni

[S.....s]

@kot1401: bawisz się w TDD - w sensie, umiesz coś już? Bo nie wiem jak rozbudowanie Ci to rozpisać :-P Projekt rozumiem jednoosobowy?

[kot1401]

@Skarfejs: znam tylko teorię TDD :P Teraz chcę zacząć to wykorzystwać w praktyce.

[tell_me_more]

@kot1401: teoretycznie to wywal klasy, serwisy, interfejsy, i zacznij od pisania testów funkcjonalności, ilość klas i podział na klasy powinien się zmieniać w trybie 3 (1=napisz 1 test nie przechodzący, 2=najprościej jak się da zrób, żeby ten test przechodził, 3=zobacz, czy nie da się czegoś zrefaktorować, powrót do punktu 1). Jak zepsujesz w którymś momencie poprzedni test któryś - to popraw tak, żeby wszystkie przechodziły. Może się okazać, że w

[S.....s]

@kot1401: wygląda to mniej więcej tak - najpierw piszesz testy funkcjonalne, czyli to co może zrobić użytkownik końcowy. Przykładowo - Adaś wchodzi na wypok.pl, klika zaloguj, gdzie widzi dwa pola formularza, po kliknięciu zostaje zalogowany i powitany wiadomością "Cześć Adaś!"

Wchodzisz na wypok.pl - nie działa, piszesz więc test jednostkowy sprawdzający czy '/' zwraca status 200. Nie zwraca, robisz więc tak długo przy projekcie aż zwróci poprawny status.

Następnie Adaś powinienen kliknąć "zaloguj" - ale tego odnośnika nie ma - więc piszesz test sprawdzający, czy po wejściu na stronę główną widać link zaloguj. Naprawiasz test - ma przechodzić. Potem sprawdzasz czy zaloguj przenosi do poprawnej strony - nie przenosi, piszesz test jednostkowy - naprawiasz, idziesz

[safjanowski]

@Skarfejs: dlaczego mówisz o testach funkcjonalnych gdy pytanie jest o #tdd?

@kot1401: książki, które mogą Cię zainteresować: Growing Object-Oriented Software, Guided by Tests – Steve Freeman oraz Test Driven Development: By Example – Kent Beck

Napoczątek „zastubować” następnie „zamokować” jak więcej będziesz wymagał od testu.

[S.....s]

@Skarfejs: dlaczego mówisz o testach funkcjonalnych gdy pytanie jest o #tdd?

@safjanowski: wytłumacz mi dlaczego testy funkcjonalne nie należą do TDD, bo chyba czegoś nie wiem? ;-)

[safjanowski]

@Skarfejs: Nie ta warstwa, testy funkcjonalne są testami integracyjnymi – to #bdd, gdzie gherkin służy do opisywania funkcjonalności.

Od #tdd oczekuję że logowanie wywołała metodę odpowiedzialną za sprawdzenie czy dany użytkownik może się zalogować bez rzeczywistego odpytywania np. bazy danych, w której przetrzymywane są loginy / hasła.

Od #bdd oczekuje przejścia przez cały proces – czy »user story« zostało pomyślnie przeprowadzone.

[S.....s]

@safjanowski: oczywiscie masz racje, ale tylko z teoretycznego punktu widzenia. Gdy ktos popelnia blad w zalozeniach tak jak robil to @kot1401 i pomimo checi nauki TDD "rozpisal" sobie kilkanascie klas w glowie to IMO najlepszym poczatkowym sposobem na nauke jest rozpisanie testow jednostkowych w oparciu o test funkcjonalny. To duzo latwiejsze, umozliwia spokojne projektowanie krok po kroku, bez zbednego dokladania aktualnie niepotrzebnych funkcjonalnosci "na pozniej". Zalozylem, ze nie pracuje