Jak mogę podzielić funkcję "pełnego stosu" na testy akceptacyjne, integracyjne i jednostkowe?

Question

Jestem nowy w Behavior Driven Development i próbuję się tego nauczyć. Używam MSpec & Watin do testów akceptacyjnych i MSpec do testów jednostkowych z ASP.Net MVC 4. Mam prosty scenariusz rejestracji użytkownika.

Gdy użytkownik wprowadzi nazwę użytkownika, hasło, e-mail itp i kliknie przycisk rejestru
Należy potwierdzić adres email
Należy sprawdzić, czy nazwa użytkownika już nie istnieje
Należy zarejestrować użytkownika
należy wysłać e-mail powitalny
należy przekierować do strony głównej

są rzeczy, które chcę przetestować, które nie mogą być testowane za pomocą Wa cyny, takie jak wysyłanie wiadomości e-mail, sprawdzanie, czy użytkownik istnieje, czy nie itp. Będą one częścią testów kontrolera. Czy oznacza to, że mój test akceptacyjny będzie tylko taki, że gdy użytkownik zarejestruje się, powinien zostać przekierowany na stronę główną? Jak mogę podzielić cały ten proces na testy?

Jeśli te kontrole są wdrażane w różnych testach i na innym poziomie, to w jaki sposób mogę uzyskać raport podsumowujący, który jest dostępny w MSPEC, że mam wdrożone wszystkie funkcje? Jestem nieco zdezorientowany, jak ludzie złamać te zadania, a następnie, w jaki sposób uzyskać raport zbiorowy itd

Answer 1

Twoje testy jednostkowe będzie składać się z czymś takim:

• Testu, że kod, który rejestruje użytkownik rzuca wyjątek, jeśli nazwa użytkownika nie została podana.
• Sprawdź, czy działa kod, który sprawdza poprawność hasła.

Zasadniczo biorąc małe jednostki kodu i testując je.

Za testy akceptacyjne, przejście do następnego poziomu i zintegrowanie tych funkcji, aby upewnić się, że działają. Więc możesz mieć test akceptacji, który sprawdza całą funkcję rejestracji:

Given I am a new user 
When I complete the register user form 
Then I will be redirected to the home page 

Given I am a new user 
When I complete the register user form 
And I have not entered a valid password 
Then I will be shown an error message 

Albo coś w tym regionie.

Osobiście nie jestem wielkim fanem pisania testów testujących interfejs użytkownika, ponieważ interfejs użytkownika może się często zmieniać (co oznacza, że ​​trzeba naprawić testy zepsute tymi zmianami); plus czułem, że powielam wysiłek, pisząc testy jednostkowe, a następnie testy akceptacyjne.

Jednak ATDD może Ci pomóc, jeśli chodzi o klienta, ponieważ możesz przekazać im informacje o tym, jak testujesz aplikację. O wiele łatwiej jest pokazać im test BDD (który jest tekstem pisanym), a następnie public void ValidatePassword_PasswordNotValid_ExpectFalse.

Jest to jeden z tych scenariuszy, w których należy wypróbować ATDD, aby dowiedzieć się, czy z niego skorzystasz.

Answer 2

Najpierw rozpocznij od testów akceptacyjnych , aby sterować swoim rozwojem (na zewnątrz). trzeba by napisać następujące scenariusze:

użytkownika spróbować zarejestrować się z nieprawidłowym email

To jest dość proste

użytkownika spróbować zarejestrować się już istniejącej nazwy logowania

na ten jeden, musisz być w stanie podłączyć swoją aplikację na zasadzie w repozytorium pamięci (bym Proponuję za pomocą IoC Container, aby łatwo skonfigurować aplikację). W ten sposób najpierw użyjesz aplikacji do zarejestrowania użytkownika "Bob" i zobaczysz, co się stanie, gdy spróbujesz zarejestrować się ponownie przy użyciu tego loginu. Zasadniczo rozwiązaniem jest użycie wzoru repozytorium i implementacja pamięci zamiast rzeczywistej implementacji DB. Zakładam, że twoja baza danych nie zawiera żadnej logiki biznesowej, w przeciwnym razie bezpieczniej byłoby używać prawdziwego DB, aby można było wykonywać reguły biznesowe w DB. To dość powszechne w starszych systemach. Zaletą repozytorium w pamięci jest to, że twoje testy będą działały szybciej i nie będziesz musiał pisać skomplikowanego kodu odrywania. Z prawdziwym DB musisz upewnić się, że DB jest czyszczony pomiędzy testami, aby zapewnić niezależność testów, a testowanie z DB jest znacznie wolniejsze.

Użytkownik pomyślnie zarejestrować

dla tego jednego trzeba będzie sprawdzić, czy przekierowania, które jest dość proste. W przypadku części wiadomości e-mail, agian, musisz podłączyć swoją aplikację do kodu pośredniczącego, używając wzoru Adapter. Można zaimplementować kod pośredniczący, taki jak w kolejce pamięci, dzięki czemu będzie można potwierdzić, czy wiadomość e-mail została poprawnie wysłana przez aplikację.

jednostki dotyczące testu

Jeśli planujesz napisać weryfikacji składni e-mail na własną rękę, chciałbym zasugerować, że część badanej jednostki na własną rękę.

Jak wspomniał Augusto, Growing Object-Oriented Software, Guided by Tests to świetna książka do nauki ATDD i TDD.

Ogólna strategia polega na tym, aby zawsze zaczynać od testów akceptacyjnych wysokiego poziomu, aby stymulować rozwój. Próbne usługi zewnętrzne, których nie można uruchomić w pamięci lub usługach, których nie można zainstalować lokalnie lub które nie są łatwe do przetestowania. Testuj urządzenie za pomocą TDD, gdy ma to sens.