[Patres]

#programowanie #testowanieoprogramowania #java #rest
Jak robię testy do aplikacji webowej (Spring) i chcę przetestować rejestracje. Jak robicie test na poprawność danych:
1. Każdy test do osobnego pola np:
a) User z wszystkimi poprawnymi polami tylko jako email "123zlyEmail",
b) User z wszystkimi poprawnymi polami tylko za krótkie hasło "123"
c) User z wszystkimi poprawnymi polami tylko bez nazwiska null
2. Jeden test do wszystkich pól:
użytkownik z email "123zlyEmail", hasłem "!23" i nazwiskiem null

[Viters]

@Patres Twój kod jest niepoprawny i dla błędnego maila wyrzuca dwa błędy - o mailu i haśle, ale błędne hasło nie triggeruje errora. Twoja druga strategia nie wychwyci tego błędu. Można "skracać" testy łącząc asercje, ale nie powinno się testować wielu różnych przypadków na raz.

[fegwegw]

@Patres: Testy to Twoja siatka bezpieczeństwa, mająca dać znać, czy wszystko działa. Jeśli masz test, który sprawdza 3 różne przypadki, i nagle przestaje przechodzić - to skąd masz wiedzieć, co się popsuło?

[A.....t]

@Patres: każdy test do osobnej walidacji, bo jak coś sie w-----e to o wiele łatwiej znaleźć co nie przeszło

[Patres]

@Viters: @fegwegw: @AwizisieAkat: Dziękuję Panowie. Tak jak myślałem.

@interface: Dzięki, poczytam!

[LiczbaPi]

@Patres: Ja bym testował wiele pól w jednym teście, ale tych testów też miał wiele np.:
- poprawne dane minimalne
- poprawne dane maksymalne
- poprawne dane w jakichś wariacjach np 2 członowe imiona czy znaki niestandardowe
- niepoprawne login i hasło
-

[fegwegw]

Generalnie najprostsza resestracja to conajmniej kilkanaście przypadków testowych, a jak dochodzą dodatkowe opcje i pola to może iść i w setki testów

@LiczbaPi: niech idzie i w tysiące, co w tym dziwnego/złego?

Taki wypok na przykład testuje bezpośrednio na produkcji - co z tego wynika, każdy widzi.

[LiczbaPi]

@fegwegw: A czy ja napisałem, że to coś dziwnego czy złego?

[kotoj]

@Patres: wszystko zależy od tego jak zbudowana jest apka. Jakby się dało to ja napisalbym 1 test, przyjmujący kilka parametrów, i dorobil do niego wiele zestawów danych wejsciowych. Takie dane to np: login, password, expectedHttpResponseCode, expectedErrorMessage. Wtedy tylko robisz odpowiednie zestawy, np dla testu pozytywnego: validLogin, validPass, 200, "". Dla niepoprawnego hasła: validLogin, invalidPass, 403, "niepoprawne hasło" itd. Każdy zestaw powinien uruchomić się jako niezależny TC