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?
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: 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
@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.
@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.
@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.
@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
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
@kot1401: co to za TDD skoro już klasy masz, a dopiero teraz myślisz jak rozpisać testy ( ͡° ͜ʖ ͡°)
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ąć
@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.
@safjanowski: wytłumacz mi dlaczego testy funkcjonalne nie należą do TDD, bo chyba czegoś nie wiem? ;-)
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.