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 (602,330 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 ;)

komentarz 2 stycznia 2017 przez Comandeer Guru (602,330 p.)

W sumie można by napisać funkcję do generowania testów, ale IMO to sztuka dla sztuki w tak prostym przypadku.

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

Dopiero teraz zauważyłem, że oprócz log, wykorzystuję się error i warn. W takim przypadku rzeczywiście powtórzenie jest tylko jedno więc można to przeżyć. Jednak dalej pisanie osobnego describe dla jednej funkcji, która nie ma w zasadzie żadnej logiki, wydaje mi się przesadą. Czy dla innych banalnych funkcji jak akcesory zmiennych również trzeba pisać testy?

1	komentarz 2 stycznia 2017 przez Comandeer Guru (602,330 p.) Powiem tak: jeśli czegoś nie trzeba testować, istnieje spora szansa, że nie musi istnieć ;) No i ponawiam pytanie: jak chciałbyś to wcisnąć w jedno describe?

komentarz 3 stycznia 2017 przez adrian17 Ekspert (345,160 p.)

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

Mockujesz API rysowania. Działania zewnętrznych komponentów się nie testuje, chyba, że masz powód by im nie ufać.

komentarz 3 stycznia 2017 przez Comandeer Guru (602,330 p.)

chyba, że masz powód by im nie ufać.

Przeglądarki mnie nauczyły, że nigdy nie należy ufać. Zamockowany kod często działa w nich bez problemu, API działa, po czym wystarczy to włożyć z powrotem w środowisko przeglądarki i już dłużej nie działa.

komentarz 4 stycznia 2017 przez adrian17 Ekspert (345,160 p.)

Uroki JSa :)

komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.)

Nah, to akurat nie ma nic wspólnego z JS-em, bo dokładnie takie same problemy są choćby przy testowaniu CSS-a. Choćby dlatego, że środowisko przeglądarek nie jest homogeniczne, a różne wersje tej samej przeglądarki mogą mieć różne bugi psujące tę samą rzecz…

komentarz 4 stycznia 2017 przez adrian17 Ekspert (345,160 p.)

s/JSa/webdevu/

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

Tyle, że te testy wcale nie sprawdzają czy przeglądarka rzeczywiście wyświetla poprawnie napis np. może nie rozumieć koloru green i wyświetlić domyślny kolor. Jedyne co te testy sprawdzają, to czy funkcje w javascripcie działają, bo przecież złośliwy javascript może nam pozamieniać kolejność argumentów, a pojedyncze wywołanie console.log może spowodować podwójne wywołanie console.log. Całe szczęście, że napisaliśmy testy i mamy pewność, że console.log rzeczywiście wywoła się tylko raz, a wredny javascript nie zmieni naszych argumentów...

komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.)

Nie, te testy sprawdzają, czy Logger.success faktycznie wywołuje pod spodem console.log z odpowiednimi parametrami itd.

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

To łatwiej byłoby za pomocą jakiegoś narzędzia pobrać kod funkcji i porównać z kodem w teście. Na to samo by wyszło, zakładając, że funkcje w javascripcie rzeczywiście działają.

komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.)

No ale to porównujesz wygląd kodu, a nie jego rzeczywiste działanie… Jaki to ma sens? Zwłaszcza jeśli testy są – tak jak tutaj – odpalane na kodzie przepuszczonym przez bundler i różni się od źródłowego.

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

Ale chyba zakładamy, że funkcje w javascripcie rzeczywiście działają i napisanie raz console.log rzeczywiście spowoduje wywołanie raz console.log.

komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.)

A ja powtarzam raz jeszcze: te testy nie sprawdzają, czy console.log działa jak ma działać tylko czy logika zawarta w Logger.success robi to, co ma robić, czyli wywołać console.log raz i to z odpowiednimi parametrami…

Jeszcze raz: te testy sprawdzają, czy napisana przez nas funkcja robi to, co ma robić. Specjalnie wybrałem prosty przykład, żeby to ładnie pokazać, ale widać, że powinienem wybrać jakiś diabelnie zawiły ;)

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

A ja jeszcze raz powtarzam, że jeśli funkcja Logger.success ma treść console.log(...) to zakładając, że funkcje w javascripcie rzeczywiście działają to mamy pewność, że console.log(...) zostanie wywołane tylko raz. To chyba oczywiste.

komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.)

Ech, załóżmy, że oprócz wywołania Logger.success logger dodatkowo wysyła e-maila do admina (i załóżmy, że nie łamiemy tutaj żadnej zasady SOLID…):

const Logger = {
	[…]
	
	success( msg ) {
		console.log( '%c OK:' , 'color: green;font-weight: bold;', msg );
		
		this.emailService.pingAdmin( msg );
	}

	[…]
}

Czy dalej nie widzisz żadnej potrzeby sprawdzenia, czy faktycznie ta funkcja wywołuje to, co ma wywołać? Im logika jest bardziej skomplikowana, tym większa szansa, że coś się skopie (np. wywołanie console.log będzie wymagało odpowiedniej wartości odpowiedniej flagi).

W przypadku funkcji, które coś zwracają, testy są prostsze, bo zwykle wystarczy sprawdzić, czy output jest dobry. W przypadku funkcji, które po prostu coś robią, wypada sprawdzić, czy faktycznie to robią.

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

Jeżeli chcemy wywołać console.log, a napiszemy console.log(...) to mamy pewność, że console.log zostanie na pewno wywołane. Jeżeli chcemy wywołać funkcje wysyłająca email i napiszemy wywołanie funkcji wysyłającej email to mamy pewność, że funkcja ta zostanie na pewno wywołana. Mówienie o logice w przypadku zwykłego wywoływania funkcji to jakiś nieporozumienie.

komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.)

Ok, to nie testuj – nie mój problem ;)

A co jeśli wywołanie tych funkcji będzie warunkowe – też nie widzisz problemu w braku testowania?

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

W przypadku warunków to już oczywiście co innego. Jest jakaś logika, która można przetestować. W przypadku loggera testujemy jedynie czy wywołanie funkcji w javascripcie działa.

1	komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.) Nie chcesz zrozumieć jednej rzeczy: nie testuję wywołania funkcji, ale działanie mojej metody. Choć w tym przypadku wychodzi na to samo, to jest to bardzo ważne przesunięcie.

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

Rozumiem, że testuje się działanie metody, ale właśnie te działanie polega jedynie na wywołaniu funkcji. Można jednak spokojnie założyć, że wywołanie funkcji w Javascripcie działa i nie ma sensu tego testować. Fajnie że jest dokumentacja, dobre pokrycie kodu testami i w ogóle, ale po co na te cztery funkcje tracić 117 linijek kodu. Gdyby istniała klasa, której jedynym zadaniem było delegowanie stu funkcji do różnych klas to nie chce nawet myśleć ile tysięcy linijek bezsensownych testów trzeba byłoby napisać.

2	komentarz 4 stycznia 2017 przez Comandeer Guru (602,330 p.) @erx700 ok, specjalnie dla Ciebie w kolejnej książce pierwsze testy napiszę dla zaawansowanego webappa ;)

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 (602,330 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 (602,330 p.) Czyli poległem jako dydaktyk :( Ale dzięki za feedback – wiem, nad czym popracować bardziej w kursie JS!