Testy integracyjne. Co i jak?

6

@Gworys:
Ależ rozumiem. Przypomina mi to po prostu kłótnie dwóch PMów czy dane zadanie to task czy story, podczas gdy dev już skończył je robić w międzyczasie,

0
yarel napisał(a):

Tak, z ciekawości, gdzie jest wartość dodana w nazywaniu na różne sposoby (mock, stub, fake) implementacji użytej na potrzeby testów ?
To nie jest tak jak z tym dowcipem o juhasach i bacy, który rozwiewa wątpliwości jak nazywać jeża poprawnie?

Myślę, że chodzi o wyrywanie lachonów z dziwnymi fetyszami. ;)

A tak na serio, to nie sądzę aby ktoś Ci odpowiedział na to pytanie. Bo odpowiedzieć mogą tylko ludzie, którzy faktycznie piszą tego typu klasy, czyli jaskiniowcy, a oni jeszcze nie wynaleźli języka.

@somekind, żeby nie zostać jaskiniowcem specjalnie rejestruje wszystkie klasy w kontenerze, żeby mógł je potem automatycznie stubować, mockować. :D

I nie trzeba się męczyć z dyskusjami na temat tego, czy prawidłowo się nazwało fejkowe klasy w projektach testowych. No chyba, że ktoś chce mieć wąską specjalizację, zostać senior test double developerem i debatować w nieskończoność, czy mock jest spy'em czy odwrotnie.

No tobie na pewno zajmie co najmniej tydzień, żeby, ustalić co jest mockiem a co stubem.

1
Wibowit napisał(a):

Teza o szybkości testów jest słaba. Nieraz jak testuję np jakiegoś aktora Akkowego to test może trwać nawet kilka sekund, bo takie sobie ustawiam timeouty. Operacje na aktorach dzieją się asynchronicznie, a test działa synchronicznie, więc trzeba robić awaity z timeoutami. Z drugiej strony mogę mieć test, który tworzy pliki na dysku, ale działa 10x szybciej. Co z tego wynika? To, że test jednostkowy niekoniecznie musi być szybki.

Raczej to, że porównujesz jabłka z poziomkami, co jakby nie bardzo ma sens. Nie chodzi o to, że jedne testy jednostkowe mogą być szybsze, a drugie wolniejsze, bo to jest truizm. Test funkcji X, do którego dane są dostarczone w pamięci będzie szybszy niż test funkcji X, do którego dane trzeba wczytać z jakiegoś pliku.

Zamiast się głowić jak kategoryzować testy albo powstrzymywać się przed stworzeniem tymczasowego pliku w teście jednostkowym w obawie, że ktoś się wścieknie

Pytanie zasadnicze - po co tworzyć pliki w testach jednostkowych? Jednostkowo testuje się przetwarzanie danych, jest wejście do którego przekazujemy wejściowe dane testowe, i wyjście, którego wynik porównujemy ze wzorcem. To wszystko. Trzeba mieć jakąś dziwną architekturę, żeby gdzieś tam po drodze się tworzyły pliki.

Natomiast to czy ja sobie w jakimś teście, który do tej pory był 100% unitowy (według wszelkich wyrytych w skałach zasad) zacznę tworzyć tymczasowy plik na dysku to jest taka pierdoła, że nie warto się nad tym pochylać. Jeśli stworzenie tymczasowego pliku umożliwi stworzenie sensownego testu (o wciąż akceptowalnej wydajności), gdzie lepiej pokrywam rzeczywisty kod biznesowy, a nie robię kolejnego testu Mockito to jak najbardziej warto taki tymczasowy plik stworzyć i zapomnieć o mockach przy testach danej klasy.

Teraz już jestem na 100% pewny, że to o jakąś dziką architekturę musi chodzić, skoro plikami zastępujesz mocki.

Gworys napisał(a):

@somekind, żeby nie zostać jaskiniowcem specjalnie rejestruje wszystkie klasy w kontenerze, żeby mógł je potem automatycznie stubować, mockować. :D

Niczego w żadnym kontenerze nie rejestruję, nawet żadnego nie mam.

No tobie na pewno zajmie co najmniej tydzień, żeby, ustalić co jest mockiem a co stubem.

Zajmuje sekundę, tylko po prostu nie mam takiej potrzeby, bo nie piszę ich ręcznie.

2

Test funkcji X, do którego dane są dostarczone w pamięci będzie szybszy niż test funkcji X, do którego dane trzeba wczytać z jakiegoś pliku.

Jeśli moje dane testowe mają kilka kilobajtów to wczytywanie ich z pliku będzie szybsze niż kompilacja klasy z takimi danymi osadzonymi w środku. Poza tym mając osobny plik łatwiej takie dane przejrzeć (np otworzyć w Excelu, przegrepować, etc) czy zastąpić innymi.

Nawet pomijając czas kompilacji czy wygodę programisty, to mając napęd SSD wczytywanie pliku będzie prawie na pewno wielokrotnie szybsze niż przetwarzanie go w testach - nie dość, że ładowanie klas implementujących testy (bądź do nich potrzebnych) sporo trwa to jeszcze dochodzi rozgrzewanie JITa, które trwa raczej wielokrotnie dłużej niż wczytywanie nawet wielokilobajtowych plików.

0
Wibowit napisał(a):

Jeśli moje dane testowe mają kilka kilobajtów to wczytywanie ich z pliku będzie szybsze niż kompilacja klasy z takimi danymi osadzonymi w środku.

Benchmarkowałeś to? Jakoś nie wierzę, że operacja I/O i deserializacja będą szybsze niż skompilowanie. No, a poza tym, to kompilacja jest jednorazowa, a czytanie z dysku musi się odbywać za każdym razem, czyż nie?

Nawet pomijając czas kompilacji czy wygodę programisty

No właśnie - wygoda programisty. Wolę mieć dane statycznie typowane, z błędami w danych wejściowych wyłapywanymi przez kompilator, niż przeszukiwać pliki pod kątem błędów typów po jakichś zmianach w strukturze danych.
Nawet, gdyby kompilacja trwała 100 razy dłużej, to i tak w ostatecznym rezultacie będzie to szybsze podejście.

1 użytkowników online, w tym zalogowanych: 0, gości: 1