AFAIK, testy jednostkowe NIE są testami funkcjonalnymi. Pozwól, że wyjaśnię małym przykładem. Chcesz sprawdzić, czy funkcjonalność logowania do aplikacji internetowej działa, czy nie, tak jak użytkownik. W tym celu powinny wyglądać twoje testy funkcjonalne.
1- existing email, wrong password -> login page should show error "wrong password"!
2- non-existing email, any password -> login page should show error "no such email".
3- existing email, right password -> user should be taken to his inbox page.
4- no @symbol in email, right password -> login page should say "errors in form, please fix them!"
Czy nasze testy funkcjonalne powinny sprawdzać, czy możemy zalogować się przy użyciu nieprawidłowych danych? Na przykład. E-mail nie ma symbolu @, nazwa użytkownika ma więcej niż jedną kropkę (dozwolona jest tylko jedna kropka), .com pojawia się przed @ itd.? Ogólnie nie! Tego rodzaju testy wchodzą w skład testów jednostkowych.
Możesz sprawdzić, czy nieprawidłowe testy są odrzucane w testach jednostkowych, jak pokazano w poniższych testach.
class LoginInputsValidator
method validate_inputs_values(email, password)
1-If email is not like string.string@myapp.com, then throw error.
2-If email contains abusive words, then throw error.
3-If password is less than 10 chars, throw error.
Zauważ, że test funkcjonalny 4 faktycznie wykonuje to, co robi test jednostkowy 1. Czasami testy funkcjonalne mogą powtórzyć niektóre (nie wszystkie) testy przeprowadzone przez testy jednostkowe, z różnych powodów. W naszym przykładzie używamy testu funkcjonalnego 4, aby sprawdzić, czy konkretny komunikat o błędzie pojawia się przy wprowadzaniu nieprawidłowych danych wejściowych. Nie chcemy sprawdzać, czy wszystkie złe dane wejściowe są odrzucane, czy nie. To jest zadanie testów jednostkowych.
