Riddle napisał(a):
- Wywal z testów te
throws DatabaseException, SQLException. Złap te wyjątki w helperach testowych i zamiast tego rzućRuntimeException. Albo ewentualnie przeróbDatabaseExceptionnaRuntimeException.
Czy w każdym teście w projekcie powinienem mieć takie podejście, aby łapać wyjątki w helperach?
Ornstein napisał(a):
Riddle napisał(a):
- Wywal z testów te
throws DatabaseException, SQLException. Złap te wyjątki w helperach testowych i zamiast tego rzućRuntimeException. Albo ewentualnie przeróbDatabaseExceptionnaRuntimeException.Czy w każdym teście w projekcie powinienem mieć takie podejście, aby łapać wyjątki w helperach?
Nie chodzi o łapanie wyjątków w helperach.
Chodzi o to, żeby test wiedział jaknajmniej o niskopoziomowych szczegółach - w tym wypadku takim szczegółem jest to, gdzie zapisani są użytkownicy. Z perspektywy testu rejestracji user mógłby być zapisany w bazie SQL, mongo, w pliku, w hashmapie, w cache'u, w kolejce czy nawet w ogóle nie zapisany - mógłby istnieć tylko w pamięci. Z perspektywy testu rejestracji nie ma to znaczenia.
Także: nie powinieneś zawsze łapać wyjątków w helperach — ale powinieneś zawsze oddzielić nieistotne rzeczy od istotnych w helperach. Innymi słowy: zastanów się, co Twój test powinien testować - odpowiedz sobie na to pytanie. Odpowiedzią mogłby np być "test testuje rejestrację", albo "płatność" albo "maile" albo cokolwiek innego. I to co test testuje zawrzyj w teście, wszystko inne w helperach.
Tylko zwróć uwagę, że odpowiedź na to pytanie mogą być dwie: np może się stać że odpowiedzią na pytanie będzie "test testuje rejestrację oraz logowanie", To jest sygnał że powinieneś zrobić dwa osobne testy - w jednym przetestuj rejestrację (i schowaj logowanie do helpera), a w drugim logowanie (i schowaj rejestrację do helpera).