Wpis z mikrobloga

#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

Testy dla pół

  • Każdy unit test sprawdzający jedną walidacje 88.6% (31)
  • Jeden unit test dla walidacji pół 11.4% (4)

Oddanych głosów: 35

  • 11
  • Odpowiedz
  • 2
@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.
  • Odpowiedz
@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?
  • Odpowiedz
@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
- niepoprawny login
- poprawny login i niepoprawne hasło
- brak danych
- dane za długie
- dane za krótkie
- niepoprawne formaty
- znaki niedozwolone
itd.
Generalnie najprostsza
  • Odpowiedz
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.
  • Odpowiedz
@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
  • Odpowiedz