Testowanie Loggera z książki Comandeera

pytanie zadane 2 stycznia 2017 w JavaScript przez erx700 Gaduła (3,430 p.)

Zastanawiam się czy tworzenie osobnej grupy testów (describe) dla jednej funkcji nie jest grubą przesadą. Z tego co dotychczas czytałem grupa testów obejmują całą klasę. Logger nie zawiera żadnej logiki więc nie widzę w ogóle sensu testowania tego modułu.

Poza tym pisanie w każdym describe afterEach i beforeEach właściwie z tą samą instrukcją łamie regułę DRY :)

Link do loggera

komentarz 2 stycznia 2017 przez Bantu Nałogowiec (34,170 p.)

Im więcej testów tym lepiej, pewne info. W pracy nie raz pisze się testy, które nic ciekawego nie robią, a życie weryfikuje, że jednak często nawet takie bezsensowne testy są w stanie zaoszczędzić masę czasu i nerwów ;)

Także, według mnie, nie ma zbytecznych testów.

komentarz 2 stycznia 2017 przez maly Nałogowiec (37,190 p.)

A jakbyś chciał to załatwić, jakimś dziedziczeniem?
Pozatym DRY niema jakiegoś szczególnie wyższego priorytetu nad KISS, a same testy często służą jako przykład/dokumentacja użycia.

komentarz 2 stycznia 2017 przez erx700 Gaduła (3,430 p.)

Myślałem, żeby zastosować globalne After i BeforEach, albo ograniczyć się do jednego describe, ale jeśli Comandeer napisał inaczej to nie wiem czy byłoby to poprawne. Może Javascript (albo Mocha) jeszcze na tyle nie dojrzał aby pisać w nim poprawny kod bez powtórzeń.

komentarz 2 stycznia 2017 przez erx700 Gaduła (3,430 p.)

Rozumiem, że jak funkcja ma rysować czerwony prostokąt na ekranie to mam się podłączyć do serwera wyświetlania systemu i sprawdzić w teście czy odpowiednia funkcja się wywołuje ? O_O

1 odpowiedź

odpowiedź 2 stycznia 2017 przez Comandeer Guru (601,450 p.)
wybrane 2 stycznia 2017 przez erx700

Najlepsza

Może Javascript (albo Mocha) jeszcze na tyle nie dojrzał aby pisać w nim poprawny kod bez powtórzeń.

A teraz mi pokaż powtórzenia w kodzie testów :)

Zauważ, że te instrukcje nie są takie same, ale operują na innych metodach obiektu console. Jasne, można sobie napisać instrukcję pomocniczą, ale wówczas po prostu przenosisz problem o warstwę abstrakcji wyżej. Można też wepchać wszystkie testy razem, ale wówczas mockujesz naraz więcej niż potrzebujesz. No i przede wszystkim: IMO byłoby to mniej czytelne.

Rozumiem, że jak funkcja ma rysować czerwony prostokąt na ekranie to mam się podłączyć do serwera wyświetlania systemu i sprawdzić w teście czy odpowiednia funkcja się wywołuje ? O_O

To zależy co testujesz. Jeśli testujesz, czy faktycznie się rysuje, to raczej innej możliwości nie ma ;)

Pokaż 22 poprzednich komentarzy

komentarz 4 stycznia 2017 przez erx700 Gaduła (3,430 p.)

W szczególności w zaawansowanym webappie istnieje dziesiątki funkcji, które nic nie robią, ale trzeba przetestować, bo przecież pojedyncze wywołanie funkcji może spowodować tak naprawdę podwójne wywołanie ;)

2	komentarz 4 stycznia 2017 przez Comandeer Guru (601,450 p.) Uwierz mi – kiedyś takie podejście Cię ugryzie, zwłaszcza w webdevie. Poza tym: funkcja, która nic nie robi, to martwy kod usuwany w czasie refaktoryzacji. Jeśli funkcja przeżyła, to znaczy, że jednak coś robi ;)

komentarz 4 stycznia 2017 przez erx700 Gaduła (3,430 p.)

Chociaż że kompletnie tych testów nie rozumiem, to wierze ci na słowo, że tak powinno być ;)

2	komentarz 4 stycznia 2017 przez Comandeer Guru (601,450 p.) Czyli poległem jako dydaktyk :( Ale dzięki za feedback – wiem, nad czym popracować bardziej w kursie JS!