Jak wybrać różne typy testów z frameworkiem testowym SpecFlow, Cucumber lub innego typu BDD?

Question

Patrzę na przykładach SpecFlow, a to MVC próbka zawiera kilka alternatyw dla testów: Testy

• akceptacji na podstawie walidacji wyników generowanych przez kontrolerów;
• Testy integracyjne za pomocą MvcIntegrationTestFramework;
• Zautomatyzowane testy akceptacyjne za pomocą Selenium;
• Ręczne testy akceptacyjne, gdy tester jest monitowany o ręczne sprawdzanie poprawności wyników.

muszę powiedzieć, że jestem pod wrażeniem, jak dobrze SpecFlow przykłady są napisane (i udało mi się uruchomić je w ciągu kilku minut po pobraniu prostu musiał skonfigurować bazę danych i zainstalować selen serwera zdalnego sterowania). Patrząc na alternatywne testy widzę, że większość z nich uzupełnia się, zamiast być alternatywą. Mogę myśleć o następujących kombinacjach tych testów:

• Kontrolery są testowane w stylu TDD zamiast używać SpecFlow (wierzę Biorąc/Kiedy/Potem rodzaj testów należy stosować na wyższy, end-to-end poziomu ; powinny one zapewnić dobre pokrycie kodu dla poszczególnych komponentów;
• MvcIntegrationTestFramework jest przydatna podczas uruchamiania testów integracyjnych podczas sesji rozwojowych, testy te są również częścią codziennie buduje;
• Chociaż testy selen oparte są zautomatyzowane, są powolne i są głównie do uruchomienia podczas sesji kontroli jakości, aby szybko sprawdzić, czy nie ma złamanej logiki na stronach i w przepływie pracy witryny;
• Ręczne testy akceptacyjne, gdy tester jest monitowany o potwierdzenie poprawności wyniku, to głównie weryfikacja wyglądu i sposobu działania strony.

Jeśli używasz SpecFlow, ogórek lub inne BDD ram kontroli przy odbiorze w was rozwoju Web, można proszę udostępniać swoje praktyki dotyczące wyboru między różnymi rodzajami testów.

Z góry dziękuję.

Answer 1

To wszystko zachowanie.

Biorąc pod uwagę określony kontekst, kiedy zdarzenie ma miejsce (w określonym zakresie), powinien nastąpić pewien wynik.

Zakres może obejmować całą aplikację, część systemu lub jedną klasę. Nawet funkcja zachowuje się w ten sposób, z wejściami jako kontekstem i wynikiem jako wyjściem (możesz użyć BDD także dla języka funkcjonalnego!)

Zwykle korzystam z frameworków Unit (NUnit, JUnit, RSpec itp.) Na poziomie klasy lub integracji, ponieważ widzowie są techniczni. Czasami dokumentuję w komentarzach Given/When/Then.

Na poziomie scenariusza staram się dowiedzieć, kto naprawdę chce pomóc w odczytywaniu lub pisaniu scenariuszy. Nawet interesariusze biznesowi mogą czytać tekst zawierający kilka kropek i nawiasów, więc głównym powodem posiadania języka naturalnego, takiego jak MSpec lub JBehave, jest pisanie scenariuszy lub pokazywanie ich osobom, które naprawdę będą zniechęcić i nawiasy.

Po tym zajrzeniu przyglądam się, w jaki sposób framework będzie odtwarzany z systemem kompilacji, oraz w jaki sposób damy możliwość czytania lub pisania zgodnie z potrzebami zainteresowanych stron.

Here's an example I wrote pokazać, co można zrobić w scenariuszach za pomocą prostych DSL. To jest napisane w NUnit.

Here's an example in the same codebase pokazano Given, When, Then w komentarzach na poziomie klasy.

Zajmuję się etapami, a następnie umieszczam ekrany lub strony za nimi, a następnie na ekranach i stronach, które nazywam dowolną strukturą automatyki, której używam - np. Selenium, Watir, WebRat, Microsoft UI Automation itp.

Podany przeze mnie sam przykład jest narzędziem automatyzacji, więc scenariusze demonstrują zachowanie narzędzia automatyzacji poprzez demonstrowanie zachowania fałszywego gui, na wypadek gdyby było to mylące. Mam nadzieję, że i tak to pomoże!

Answer 2

Ponieważ testy akceptacyjne są rodzajem testów funkcjonalnych, ogólnym celem jest przetestowanie aplikacji z nimi od końca do końca. Z drugiej strony, być może trzeba będzie rozważyć efektywność (ile wysiłku wymaga wdrożenie automatyzacji testów), łatwość konserwacji, wydajność i niezawodność automatyzacji testów. Ważne jest również, aby automatyzacja testów mogła łatwo dopasować się do procesu tworzenia, tak aby wspierała rodzaj "testu najpierw" (w celu wsparcia rozwoju na zewnątrz).

To jest kompromis, który może być inny dla każdej sytuacji (dlatego dostarczyliśmy alternatywy).

Jestem prawie pewien, że obecnie najbardziej odpowiednią opcją jest testowanie na warstwie kontrolera. (Może później, gdy struktury automatyzacji UI i UI ewoluują, to się zmieni.)