Rozwój oparty na zachowaniu - krótki przewodnik
Behavior Driven Development (BDD) to proces tworzenia oprogramowania, który pierwotnie wyłonił się z Test Driven Development (TDD).
Według Dana Northa, który jest odpowiedzialny za ewolucję BDD, „BDD wykorzystuje przykłady na wielu poziomach, aby stworzyć wspólne zrozumienie i niepewność w dostarczaniu oprogramowania, które ma znaczenie”.
BDD używa przykładów, aby zilustrować zachowanie systemu, które są napisane czytelnym i zrozumiałym językiem dla wszystkich zaangażowanych w rozwój. Te przykłady obejmują -
Konwertowane na wykonywalne specyfikacje.
Używany jako testy akceptacyjne.
BDD - kluczowe cechy
Rozwój oparty na zachowaniu koncentruje się na -
Zapewnienie wspólnego procesu i wspólnych narzędzi promujących komunikację z twórcami oprogramowania, analitykami biznesowymi i interesariuszami w celu współpracy przy tworzeniu oprogramowania w celu dostarczenia produktu o wartości biznesowej.
Co system powinien robić, a nie jak powinien być wdrażany.
Zapewnienie lepszej czytelności i widoczności.
Weryfikacja nie tylko działania oprogramowania, ale także tego, czy spełnia ono oczekiwania klienta.
Pochodzenie BDD
Koszt naprawy wady wzrasta wielokrotnie, jeśli defekt nie zostanie wykryty we właściwym czasie i naprawiony w momencie wykrycia. Rozważmy następujący przykład.
Pokazuje to, że bez prawidłowego uzyskania wymagań naprawianie usterek wynikających z niezrozumienia wymagań na późniejszym etapie byłoby kosztowne. Ponadto produkt końcowy może nie spełniać oczekiwań klienta.
Potrzeba godziny to podejście do rozwoju, które -
Opiera się na wymaganiach.
Koncentruje się na wymaganiach w trakcie rozwoju.
Zapewnia spełnienie wymagań.
Podejściem programistycznym, które może zająć się powyższymi wymaganiami, jest BDD. Tak więc rozwój oparty na zachowaniu -
Wyprowadza przykłady różnych oczekiwanych zachowań systemu.
Umożliwia pisanie przykładów w języku z wykorzystaniem terminów domeny biznesowej, aby zapewnić łatwe zrozumienie przez wszystkich zaangażowanych w rozwój, w tym klientów.
Pobiera od czasu do czasu przykłady w drodze rozmów z klientem.
Koncentruje się na wymaganiach klienta (przykładach) w całym rozwoju.
Używa przykładów jako testów akceptacyjnych.
Praktyki BDD
Dwie główne praktyki BDD to:
Specyfikacja na przykładzie (SbE)
Rozwój oparty na testach (TDD)
Specyfikacja na przykładzie
Specyfikacja według przykładu (SbE) wykorzystuje przykłady w rozmowach, aby zilustrować reguły biznesowe i zachowanie oprogramowania, które ma zostać zbudowane.
Specyfikacja na przykładzie umożliwia właścicielom produktów, analitykom biznesowym, testerom i programistom wyeliminowanie typowych nieporozumień dotyczących wymagań biznesowych.
Rozwój oparty na testach
Programowanie sterowane testami, w kontekście BDD, zamienia przykłady w czytelne dla człowieka, wykonywalne specyfikacje.
Twórcy używają tych specyfikacji jako wskazówek do wdrażania kolejnych nowych funkcji. Skutkuje to oszczędną bazą kodową i zestawem automatycznych testów regresyjnych, które utrzymują koszty utrzymania na niskim poziomie przez cały okres użytkowania oprogramowania.
Agile BDD
W zwinnym tworzeniu oprogramowania metoda BDD jest wykorzystywana do wspólnego zrozumienia oczekujących specyfikacji.
Poniższe kroki są wykonywane w Agile BDD -
Deweloperzy i właściciel produktu wspólnie piszą oczekujące specyfikacje w zwykłym edytorze tekstowym.
Właściciel produktu określa zachowania, których oczekuje od systemu.
Twórcy
Wypełnij specyfikacje tymi szczegółami zachowania.
Zadawaj pytania na podstawie ich zrozumienia systemu.
Bieżące zachowania systemowe są brane pod uwagę, aby sprawdzić, czy nowa funkcja przerwie którąkolwiek z istniejących funkcji.
Manifest Agile i BDD
Manifest Agile stwierdza, co następuje:
Odkrywamy lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym. Dzięki tej pracy doszliśmy do wartości -
Individuals and interactions - ponad Procesy i narzędzia
Working software - ponad Kompleksowa dokumentacja
Customer collaboration - ponad negocjacje umowy
Responding to change - ponad Przestrzeganie planu
Oznacza to, że podczas gdy elementy po prawej stronie mają wartość, bardziej cenimy elementy po lewej stronie.
BDD dostosowuje się do manifestu Agile w następujący sposób -
| Manifest Agile | Wyrównanie BDD |
|---|---|
| Osoby i interakcje nad procesami i narzędziami. | BDD polega na prowadzeniu rozmów. |
| Działające oprogramowanie ponad obszerną dokumentację. | BDD koncentruje się na ułatwianiu tworzenia oprogramowania o wartości biznesowej. |
| Współpraca z klientem zamiast negocjacji umowy. | BDD koncentruje się na scenariuszach opartych na pomysłach z ciągłą komunikacją z klientem w miarę postępu prac. Nie opiera się na żadnych obietnicach. |
| Reagowanie na zmianę zgodnie z planem. | BDD stawia na ciągłą komunikację i współpracę, która ułatwia przyswajanie zmian. |
Kiedy spojrzysz na jakiekolwiek odniesienie do Behavior Driven Development, zauważysz użycie zwrotów, takich jak „BDD pochodzi z TDD”, „BDD i TDD”. Aby wiedzieć, jak powstało BDD, dlaczego mówi się, że wywodzi się z TDD i czym jest BDD i TDD, trzeba mieć zrozumienie TDD.
Dlaczego testowanie?
Na początek przejdźmy do podstaw testowania. Celem testowania jest upewnienie się, że budowany system działa zgodnie z oczekiwaniami. Rozważmy następujący przykład.
Dlatego z doświadczenia nauczyliśmy się, że odkrycie usterki w momencie jej wprowadzenia i natychmiastowe jej naprawienie byłoby opłacalne. Dlatego istnieje konieczność pisania przypadków testowych na każdym etapie tworzenia i testowania. Tego właśnie nauczyły nas nasze tradycyjne praktyki testowania, które często określa się jako wczesne testy.
To podejście do testowania jest określane jako podejście Test-Last, ponieważ testowanie jest wykonywane po zakończeniu etapu.
Wyzwania związane z podejściem testowym
Podejście Test-Last było stosowane przez dłuższy czas w projektach tworzenia oprogramowania. Jednak w rzeczywistości przy takim podejściu, ponieważ testowanie musi poczekać do zakończenia określonego etapu, często jest pomijane z powodu:
Opóźnienia w ukończeniu etapu.
Napięte harmonogramy.
Skoncentruj się na dostawie na czas, pomijając testy.
Ponadto, w podejściu Test-Last, testy jednostkowe, które mają być wykonywane przez programistów, są często pomijane. Różne znalezione powody są oparte na sposobie myślenia twórców -
Są programistami, a nie testerami.
Testowanie jest obowiązkiem testerów.
Są wydajne w kodowaniu, a ich kod nie miałby wad.
Skutkuje to -
Kompromis w zakresie jakości dostarczonego produktu.
Odpowiedzialność za jakość ponoszą tylko testerzy.
Wysokie koszty naprawy usterek, przesyłka pocztowa.
Brak możliwości uzyskania satysfakcji klienta, co oznaczałoby również utratę powtarzalnych transakcji, a tym samym wpływa na wiarygodność.
Te czynniki wymagały zmiany paradygmatu, skupienia się na testowaniu. Rezultatem było podejście Test-First.
Podejście najpierw test
Podejście Test-First zastępuje sposób programowania od wewnątrz (napisz kod, a następnie test) na zewnętrzny (napisz test, a następnie kod).
To podejście jest uwzględnione w następujących metodologiach tworzenia oprogramowania (które również są zwinne) -
miXtreme Programowanie (XP).
Test Drozdarty Drozwój (TDD).
W tych metodologiach deweloper projektuje i zapisuje testy jednostkowe dla modułu kodu przed napisaniem pojedynczego wiersza modułu kodu. Deweloper tworzy następnie moduł kodu w celu przejścia testu jednostkowego. Dlatego te metodologie wykorzystują testy jednostkowe do kierowania rozwojem.
Podstawową kwestią, aby zauważyć, że celem jest rozwój oparty na testowaniu.
Cykl czerwony-zielony-refaktor
Programowanie sterowane testami służy do tworzenia kodu na podstawie testów jednostkowych.
Step 1 - Rozważ moduł kodu, który ma zostać napisany.
Step 2 - Napisz test
Step 3 - Uruchom test.
Test kończy się niepowodzeniem, ponieważ kod nadal nie jest napisany. Dlatego krok 2 jest zwykle określany jako napisanie testu, który zakończy się niepowodzeniem.
Step 4 - Napisz minimalny kod możliwy do zaliczenia testu.
Step 5- Przeprowadź wszystkie testy, aby upewnić się, że nadal zdają. Testy jednostkowe są zautomatyzowane, aby ułatwić ten krok.
Step 6 - Refaktoryzacja.
Step 7 - Powtórz kroki od 1 do 6 dla następnego modułu kodu.
Każdy cykl powinien być bardzo krótki, a typowa godzina powinna zawierać wiele cykli.
Jest to również popularnie znane jako Red-Green-Refactor cykl, gdzie -
Red - Pisanie testu, który kończy się niepowodzeniem.
Green - Pisanie kodu do zaliczenia testu.
Refactor - Usuń powielanie i popraw kod do akceptowalnych standardów.
Kroki procesu TDD
Poniżej zilustrowano etapy procesu TDD.
Zalety TDD
Korzyści lub zalety programowania sterowanego testami:
Deweloper musi najpierw zrozumieć, jaki powinien być pożądany wynik i jak go przetestować przed utworzeniem kodu.
Kod składnika jest zakończony tylko wtedy, gdy test zakończy się pomyślnie, a kod zostanie zreformowany. Zapewnia to testowanie i refaktoryzację, zanim programista przejdzie do następnego testu.
Ponieważ zestaw testów jednostkowych jest uruchamiany po każdym refaktoryzacji, informacja zwrotna, że każdy składnik nadal działa, jest stała.
Testy jednostkowe działają jak żywa dokumentacja, która jest zawsze zgodna z danymi.
Jeśli zostanie znaleziona wada, programista tworzy test, aby ujawnić tę wadę, a następnie zmodyfikuje kod, tak aby test przeszedł pomyślnie, a defekt został naprawiony. Skraca to czas debugowania. Wszystkie inne testy również są uruchamiane, a po ich przejściu zapewnia to, że istniejąca funkcjonalność nie zostanie uszkodzona
Deweloper może w dowolnym momencie podejmować decyzje projektowe i dokonywać refaktoryzacji, a przeprowadzenie testów zapewnia, że system nadal działa. To sprawia, że oprogramowanie jest łatwe w utrzymaniu.
Deweloper ma pewność, że wprowadzi dowolną zmianę, ponieważ jeśli zmiana wpłynie na jakąkolwiek istniejącą funkcjonalność, to samo zostanie ujawnione przez uruchomienie testów, a usterki można natychmiast naprawić.
Przy każdym kolejnym uruchomieniu testowym weryfikowane są również wszystkie poprzednie poprawki defektów, a powtarzalność tego samego defektu jest ograniczona.
Ponieważ większość testów jest wykonywana podczas samego rozwoju, testowanie przed dostawą jest skrócone.
Wady TDD
Punktem wyjścia są User Stories, opisujące zachowanie systemu. Dlatego programiści często napotykają następujące pytania -
Kiedy testować?
Co przetestować?
Jak sprawdzić, czy specyfikacja jest spełniona?
Czy kod zapewnia wartość biznesową?
Błędne przekonania na temat TDD
W branży istnieją następujące błędne przekonania, które wymagają wyjaśnienia.
| Nieporozumienie | Wyjaśnienie |
|---|---|
| TDD polega na testowaniu i automatyzacji testów. | TDD to metodologia programistyczna wykorzystująca podejście Test-First. |
| TDD nie obejmuje żadnego projektu. | TDD obejmuje krytyczną analizę i projektowanie w oparciu o wymagania. Projekt pojawia się podczas rozwoju. |
| TDD jest tylko na poziomie Jednostki. | TDD może być używany na poziomie integracji i systemu. |
| TDD nie może być używane przez tradycyjne projekty testowe. | TDD stał się popularny w programowaniu ekstremalnym i jest używany w innych metodologiach Agile. Można go jednak używać również w tradycyjnych projektach testowych. |
| TDD to narzędzie. | TDD jest metodologią programistyczną i po przejściu każdego nowego testu jednostkowego jest dodawany do pakietu Automation Test Suite, ponieważ wszystkie testy muszą być uruchamiane za każdym razem, gdy dodawany jest nowy kod lub modyfikowany jest istniejący kod, a także po każdej refaktoryzacji. Dlatego narzędzia do automatyzacji testów obsługujące TDD ułatwiają ten proces. |
| TDD oznacza przekazanie deweloperom testów akceptacyjnych. | TDD nie oznacza przekazywania deweloperom testów akceptacyjnych. |
Akceptacja TDD
Acceptance Test Driven Development (ATDD) definiuje kryteria akceptacji i testy akceptacji podczas tworzenia historii użytkowników, na wczesnym etapie rozwoju. ATDD koncentruje się na komunikacji i wspólnym zrozumieniu między klientami, programistami i testerami.
Kluczowe praktyki w ATDD są następujące -
Omów rzeczywiste scenariusze, aby zbudować wspólne zrozumienie domeny.
Skorzystaj z tych scenariuszy, aby uzyskać kryteria akceptacji.
Zautomatyzuj testy akceptacyjne.
Skoncentruj rozwój na tych testach.
Użyj testów jako specyfikacji na żywo, aby ułatwić wprowadzenie zmian.
Korzyści z używania ATDD są następujące -
Wymagania są jednoznaczne i pozbawione luk funkcjonalnych.
Inni rozumieją specjalne przypadki, które przewidują programiści.
Testy akceptacji kierują rozwojem.
TDD Vs BDD
Według Dana Northa programiści zwykle napotykają następujące problemy podczas wykonywania programowania sterowanego testami -
Gdzie zacząć
Co testować, a czego nie
Ile przetestować za jednym razem
Jak nazwać ich testy
Jak zrozumieć, dlaczego test się nie udał
Rozwiązaniem wszystkich tych problemów jest rozwój oparty na zachowaniu. Wyewoluował z ustalonych praktyk zwinnych i został zaprojektowany, aby uczynić je bardziej dostępnymi i skutecznymi dla zespołów, jako nowość w zwinnym dostarczaniu oprogramowania. Z biegiem czasu BDD urosło i obejmuje szerszy obraz analizy zwinnej i zautomatyzowanych testów akceptacyjnych.
Główny difference between TDD and BDD czy to -
TDD opisuje, jak działa oprogramowanie.
Z drugiej strony BDD -
Opisuje, w jaki sposób użytkownik końcowy korzysta z oprogramowania.
Sprzyja współpracy i komunikacji.
Podkreśla przykłady zachowań Systemu.
Celuje w wykonywalne specyfikacje zaczerpnięte z przykładów
W TDD termin „testy akceptacyjne” jest mylący. Testy akceptacyjne faktycznie reprezentują oczekiwane zachowanie systemu. W praktykach Agile kładzie się nacisk na współpracę całego zespołu oraz interakcje z klientem i innymi interesariuszami. To spowodowało konieczność stosowania terminów, które są łatwo zrozumiałe dla wszystkich zaangażowanych w projekt.
TDD sprawia, że myślisz o wymaganym Behavior dlatego termin „zachowanie” jest bardziej przydatny niż termin ‘Test’. BDD to programowanie sterowane testami ze słownictwem, które koncentruje się na zachowaniu, a nie na testach.
Mówiąc słowami Dana Northa: „Przekonałem się, że przejście od myślenia w testach do myślenia w zachowaniu jest tak głębokie, że zacząłem nazywać TDD jako BDD lub Behavior Driven Development.” TDD skupia się na tym, jak coś będzie działać, BDD skupia się na tym, dlaczego w ogóle to budujemy.
BDD odpowiada na następujące pytania, z którymi często spotykają się twórcy:
| Pytanie | Odpowiedź |
|---|---|
| Gdzie zacząć? | od zewnątrz do wewnątrz |
| Co przetestować? | Historie użytkownika |
| Czego nie testować? | coś jeszcze |
Odpowiedzi te dają następującą strukturę opowieści -
Story Framework
Jak [Role]
chcę [Feature]
po to aby [Benefit]
To znaczy: „Kiedy Feature jest wykonywany, wynikowy Benefit jest dla osoby grającej Role.'
BDD dodatkowo odpowiada na następujące pytania -
| Pytanie | Odpowiedź |
|---|---|
| Ile przetestować za jednym razem? | bardzo mało skoncentrowany |
| Jak nazwać ich testy? | szablon zdania |
| Jak zrozumieć, dlaczego test się nie udał | dokumentacja |
Odpowiedzi te dają przykładowe ramy w następujący sposób -
Example Framework
Given jakiś kontekst początkowy,
When zdarzenie ma miejsce,
Then zapewnić pewne wyniki.
Oznacza to: „Zaczynając od kontekstu początkowego, kiedy ma miejsce określone wydarzenie, wiemy, jakie są jego skutki should be”.
Tak więc przykład pokazuje oczekiwane zachowanie systemu. Przykłady służą do zilustrowania różnych scenariuszy działania systemu.
Historia i scenariusze
Rozważmy następującą ilustrację autorstwa Dana Northa dotyczącą systemu bankomatów.
Fabuła
As a klient,
I want do wypłaty gotówki z bankomatu,
so that Nie muszę czekać w kolejce do banku.
Scenariusze
Istnieją dwa możliwe scenariusze tej historii.
Scenario 1 - Konto jest kredytowane
Given konto jest kredytowane
And karta jest ważna
And dystrybutor zawiera gotówkę
When klient żąda gotówki
Then upewnić się, że konto zostało obciążone
And upewnić się, że wydano gotówkę
And upewnij się, że karta została zwrócona
Scenario 2 - Konto przekroczyło limit debetu
Given konto jest przekroczone
And karta jest ważna
When klient żąda gotówki
Then upewnij się, że wyświetlany jest komunikat o odrzuceniu
And upewnij się, że gotówka nie zostanie wydana
And upewnij się, że karta została zwrócona
Wydarzenie jest takie samo w obu scenariuszach, ale kontekst jest inny. Stąd wyniki są różne.
Cykl rozwoju
Cykl rozwoju BDD to plik outside-in podejście.
Step 1- Napisz przykład wysokiej (zewnętrznej) wartości biznesowej (używając Cucumber lub RSpec / Capybara), który będzie czerwony. (RSpec tworzy framework BDD w języku Ruby)
Step 2 - Napisz niższy (wewnętrzny) przykład RSpec dla pierwszego kroku implementacji, który zostanie oznaczony na czerwono.
Step 3 - Zaimplementuj minimalny kod, aby przekazać ten przykład niższego poziomu, zobacz, czy będzie zielony.
Step 4 - Napisz następny przykład RSpec niższego poziomu, przechodząc do kroku 1, który staje się czerwony.
Step 5 - Powtarzaj kroki 3 i 4, aż przykład wysokiego poziomu w kroku 1 stanie się zielony.
Note - Należy pamiętać o następujących kwestiach -
Red/green stan to status pozwolenia.
Gdy testy niskiego poziomu są zielone, masz uprawnienia do pisania nowych przykładów lub refaktoryzacji istniejącej implementacji. Nie możesz, w kontekście refaktoryzacji, dodawać nowej funkcjonalności / elastyczności.
Gdy testy niskiego poziomu są czerwone, masz uprawnienia do pisania lub zmiany kodu implementacji tylko po to, aby istniejące testy stały się zielone. Musisz oprzeć się pokusie napisania kodu, aby przejść kolejny test, który nie istnieje, lub zaimplementować funkcje, które uważasz za dobre (klient by o to nie poprosił).
Według Gojko Adzicia, autora „Specification by Example”, Specification by Example to zestaw wzorców procesowych, które ułatwiają zmianę oprogramowania, aby zapewnić sprawne dostarczenie właściwego produktu ”.
Specyfikacja według przykładu to oparte na współpracy podejście do definiowania wymagań i testów funkcjonalnych zorientowanych na biznes dla oprogramowania, oparte na wychwytywaniu i ilustrowaniu wymagań przy użyciu realistycznych przykładów zamiast abstrakcyjnych stwierdzeń.
Specyfikacja na przykładzie - przegląd
Celem Specyfikacji na przykładzie jest skupienie się na opracowaniu i dostarczeniu uszeregowanych pod względem ważności, weryfikowalnych wymagań biznesowych. Chociaż sama koncepcja specyfikacji przez przykład jest stosunkowo nowa, jest po prostu przeformułowaniem istniejących praktyk.
Obsługuje bardzo specyficzne, zwięzłe słownictwo znane jako wszechobecny język, który -
Włącza wymagania wykonywalne.
Jest używany przez wszystkich w zespole.
Jest tworzony przez wielofunkcyjny zespół.
Przechwytuje zrozumienie każdego.
Specyfikacja według przykładu może służyć jako bezpośredni wkład w tworzenie testów automatycznych, które odzwierciedlają domenę biznesową. Dlatego też specyfikacja według przykładu skupia się na budowaniu właściwego produktu i budowaniu właściwego produktu.
Cel specyfikacji na przykładzie
Podstawowym celem Specyfikacji przez Przykład jest zbudowanie odpowiedniego produktu. Koncentruje się na wspólnym zrozumieniu, ustanawiając w ten sposób jedno źródło prawdy. Umożliwia automatyzację kryteriów akceptacji, tak aby skupić się na zapobieganiu defektom, a nie na ich wykrywaniu. Promuje również wczesne testowanie, aby wcześnie wykryć defekty.
Korzystanie z SbE
Specyfikacja według przykładu służy do zilustrowania oczekiwanego zachowania systemu, które opisuje wartość biznesową. Ilustracja przedstawia konkretne przykłady z życia. Te przykłady są używane do tworzenia wykonywalnych wymagań, które są -
Testowalne bez tłumaczenia.
Przechwycone w dokumentacji na żywo.
Oto powody, dla których używamy przykładów, aby opisać poszczególne specyfikacje -
Są łatwiejsze do zrozumienia.
Trudniej je źle zinterpretować.
Zalety SbE
Zalety korzystania ze specyfikacji na przykładzie:
Wyższa jakość
Mniejsza ilość odpadów
Zmniejszone ryzyko wad produkcyjnych
Skoncentrowany wysiłek
Zmiany można wprowadzać bezpieczniej
Lepsze zaangażowanie biznesowe
Zastosowania SbE
Specyfikacja według przykładu znajdź aplikacje w -
Albo złożona firma, albo złożona organizacja.
Nie działa dobrze w przypadku problemów czysto technicznych.
Nie działa dobrze w przypadku oprogramowania ukierunkowanego na interfejs użytkownika.
Może być również stosowany w starszych systemach.
SbE i testy akceptacyjne
Zalety specyfikacji przez przykład w zakresie testów akceptacyjnych to:
Na jednej ilustracji przedstawiono szczegółowe wymagania i testy
Postęp projektu w zakresie testów akceptacyjnych -
Każdy test ma na celu sprawdzenie zachowania.
Test jest pozytywny dla zachowania lub nie.
Zdany test oznacza, że określone zachowanie zostało zakończone.
Jeśli projekt, który wymaga ukończenia 100 zachowań, ma ukończonych 60 zachowań, to jest ukończony w 60%.
Testerzy przechodzą od naprawiania defektów do zapobiegania defektom i uczestniczą w projektowaniu rozwiązania.
Automatyzacja umożliwia natychmiastowe zrozumienie wpływu zmiany wymagań na rozwiązanie.
Specyfikacja na przykładzie - co to oznacza dla różnych ról
Celem Specyfikacji na przykładzie jest promowanie współpracy wszystkich członków zespołu, w tym klienta w całym projekcie, w celu dostarczenia wartości biznesowej. Dla lepszego zrozumienia wszyscy używają tego samego Słownictwa.
| Rola | Korzystanie z SbE |
|---|---|
| Analityk Biznesowy |
|
| Deweloper |
|
| Próbnik |
|
| Wszyscy |
|
SbE - zestaw wzorców procesu
Jak widzieliśmy na początku tego rozdziału, Specyfikacja na podstawie przykładu jest zdefiniowana jako zestaw wzorców procesowych, które ułatwiają wprowadzanie zmian w oprogramowaniu, aby zapewnić wydajne dostarczanie właściwego produktu.
Wzorce procesów to -
Wspólna specyfikacja
Zilustrowanie specyfikacji za pomocą przykładów
Dopracowanie specyfikacji
Automatyzacja przykładów
Częste sprawdzanie poprawności
Żywa dokumentacja
Specyfikacja dotycząca współpracy
Cele wspólnej specyfikacji to:
Zdobądź różne role w zespole, aby mieć wspólne zrozumienie i wspólne słownictwo.
Zaangażuj wszystkich w projekt, aby mogli wnieść swój wkład z różnych perspektyw na temat funkcji.
Zapewnij współdzieloną komunikację i własność funkcji.
Cele te są osiągane podczas warsztatów specyfikacji znanych również jako spotkanie Trzech Amigos. Trzej Amigos to BA, QA i programista. Chociaż w projekcie są inne role, te trzy osoby byłyby odpowiedzialne i rozliczane od zdefiniowania do dostarczenia funkcji.
During the meeting −
Analityk biznesowy (BA) przedstawia wymagania i testy nowej funkcji.
Trzej Amigos (licencjat, programista i QA) omawiają nową funkcję i przeglądają specyfikacje.
Kontrola jakości i programista również identyfikują brakujące wymagania.
Trzej Amigos
Wykorzystaj wspólny model, używając wszechobecnego języka.
Używaj słownictwa dziedzinowego (w razie potrzeby utrzymywany jest słownik).
Szukaj różnic i konfliktów.
Na tym etapie nie przechodź do szczegółów implementacji.
Osiągnij konsensus co do tego, czy funkcja została określona wystarczająco.
Wspólne poczucie wymagań i własność testów ułatwiają specyfikacje jakości
Wymagania są przedstawiane jako scenariusze, które zapewniają wyraźne, jednoznaczne wymagania. Scenariusz jest przykładem zachowania systemu z perspektywy użytkowników.
Zilustrowanie specyfikacji za pomocą przykładów
Scenariusze są określane przy użyciu struktury Given-When-Then w celu utworzenia testowalnej specyfikacji -
Given <pewne warunki wstępne>
And <dodatkowe warunki wstępne> Optional
When <następuje działanie / wyzwalacz>
Then <stan postu>
And <dodatkowe warunki ogłoszenia> Optional
Ta specyfikacja jest przykładem zachowania systemu. Stanowi również kryterium akceptacji systemu.
Zespół omawia przykłady, a informacje zwrotne są uwzględniane, dopóki nie zostanie ustalone, że przykłady obejmują oczekiwane zachowanie funkcji. Zapewnia to dobre pokrycie testu.
Udoskonalenie specyfikacji
Aby udoskonalić specyfikację,
Podaj dokładne przykłady. Jeśli przykład okaże się złożony, podziel go na prostsze przykłady.
Skoncentruj się na perspektywie biznesowej i unikaj szczegółów technicznych.
Rozważ zarówno pozytywne, jak i negatywne warunki.
Przestrzegaj słownictwa specyficznego dla domeny.
Omów przykłady z klientem.
Wybierz rozmowy, aby to osiągnąć.
Weź pod uwagę tylko te przykłady, którymi interesuje się klient. Umożliwia to wytworzenie tylko wymaganego kodu i pozwala uniknąć pokrycia wszystkich możliwych kombinacji, które mogą nie być wymagane
Aby upewnić się, że scenariusz przejdzie pomyślnie, wszystkie przypadki testowe dla tego scenariusza muszą przejść. Dlatego ulepsz specyfikacje, aby były testowalne. Przypadki testowe mogą obejmować różne zakresy i wartości danych (przypadki graniczne i narożne), a także różne reguły biznesowe powodujące zmiany w danych.
Określ dodatkowe reguły biznesowe, takie jak złożone obliczenia, manipulacja / transformacja danych itp.
Uwzględnij niefunkcjonalne scenariusze (np. Wydajność, obciążenie, użyteczność itp.) Jako specyfikację według przykładu
Automatyzacja przykładów
Warstwa automatyzacji musi być bardzo prosta - wystarczy podłączyć specyfikację do testowanego systemu. Możesz użyć narzędzia do tego samego.
Wykonuj automatyzację testów przy użyciu języka specyficznego dla domeny (DSL) i pokaż wyraźne połączenie między wejściami i wyjściami. Skoncentruj się na specyfikacji, a nie na skrypcie. Upewnij się, że testy są dokładne, łatwe do zrozumienia i testowalne.
Częste sprawdzanie poprawności
Dołącz przykładową walidację do swojego potoku programistycznego przy każdej zmianie (dodaniu / modyfikacji). Istnieje wiele technik i narzędzi, które można (i należy) zastosować w celu zapewnienia jakości produktu. Obracają się wokół trzech kluczowych zasad:Test Early, Test Well i Test Often.
Wykonuj testy często, aby móc zidentyfikować słabe ogniwa. Przykłady przedstawiające zachowania pomagają śledzić postęp, a zachowanie jest uważane za kompletne dopiero po pomyślnym przejściu odpowiedniego testu.
Żywa dokumentacja
Staraj się, aby specyfikacje były jak najprostsze i krótkie. Zorganizuj specyfikacje i rozwijaj je w miarę postępu prac. Udostępnij dokumentację wszystkim członkom zespołu.
Specyfikacja według przykładowych etapów procesu
Ilustracja przedstawia etapy procesu w specyfikacji na przykładzie.
Anty-wzory
Anty-wzorce to pewne wzorce w tworzeniu oprogramowania, które są uważane za złą praktykę programistyczną. W przeciwieństwie do wzorców projektowych, które są powszechnym podejściem do typowych problemów, które zostały sformalizowane i są ogólnie uważane za dobrą praktykę rozwojową, anty-wzorce są przeciwieństwem i są niepożądane
Anty-wzorce powodują różne problemy.
| Anty-wzór | Problemy |
|---|---|
| Brak współpracy |
|
| Nieświadomy zakończenia kodu |
|
| Zbyt szczegółowe lub zbyt skoncentrowane na interfejsie przykłady |
|
| Wymagane niedocenianie wysiłku |
|
Rozwiązanie problemów - Jakość
Jakość można zapewnić, obserwując anty-wzorce. Aby zminimalizować problemy stwarzane przez anty-wzorce, powinieneś -
Zbierzcie się, aby określić na podstawie przykładów.
Oczyść i popraw przykłady.
Napisz kod, który spełnia podane przykłady
Zautomatyzuj przykłady i wdrażaj.
Powtórz to podejście dla każdej historyjki użytkownika.
Aby rozwiązać problemy związane z anty-wzorcami, oznacza przestrzeganie -
Collaboration.
Skupiając się na czym.
Koncentrując się na biznesie.
Być przygotowanym.
Zrozummy, co oznacza każde z powyższych.
Współpraca
We współpracy -
Ludzie biznesu, programiści i testerzy przekazują informacje z własnej perspektywy.
Zautomatyzowane przykłady dowodzą, że zespół zbudował to, co właściwe.
Proces jest cenniejszy niż same testy.
Skupiając się na czym
Musisz skupić się na pytaniu - „co”. Skupiając się na tym „co” -
Nie próbuj opisywać wszystkich możliwych przypadków.
Nie zapomnij skorzystać z różnego rodzaju testów.
Postaraj się, aby przykłady były jak najprostsze.
Przykłady powinny być łatwo zrozumiałe dla użytkowników systemu.
Narzędzia nie powinny odgrywać ważnej roli podczas warsztatów.
Koncentrując się na biznesie
Skoncentruj się na biznesie -
Zachowaj specyfikację zgodną z zamierzeniami biznesowymi
Uwzględnij biznes w tworzeniu i przeglądaniu specyfikacji.
Ukryj wszystkie szczegóły w warstwie automatyzacji.
Być przygotowanym
Przygotuj się na następujące -
Korzyści nie są widoczne od razu, nawet gdy zmieniają się praktyki zespołu.
Wprowadzenie SbE jest trudne.
Wymaga czasu i inwestycji.
Testowanie automatyczne nie jest darmowe.
Przybory
Korzystanie z narzędzi nie jest obowiązkowe w przypadku specyfikacji na podstawie przykładu, chociaż w praktyce dostępnych jest kilka narzędzi. Zdarzają się przypadki, w których postępowanie zgodnie ze Specyfikacją przez Przykład przebiega pomyślnie, nawet bez użycia narzędzia.
Następujące narzędzia obsługują specyfikację według przykładu -
Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog
Zespoły programistyczne często mają błędne przekonanie, że BDD jest strukturą narzędziową. W rzeczywistości BDD jest podejściem programistycznym, a nie ramą narzędziową. Jednak, podobnie jak w przypadku innych podejść rozwojowych, istnieją również narzędzia dla BDD.
Kilka narzędzi BDD jest używanych dla różnych platform i języków programowania. Oni są -
Cucumber (framework Ruby)
SpecFlow (platforma .NET)
Behave (framework Python)
JBehave (platforma Java)
JBehave Web (framework Java z integracją Selenium)
Sałata (framework Pythona)
Concordion (framework Java)
Behat (framework PHP)
Kahlan (framework PHP)
DaSpec (framework JavaScript)
Jasmine (framework JavaScript)
Cucumber-js (framework JavaScript)
Squish GUI Tester (narzędzie BDD do testowania GUI dla JavaScript, Python, Perl, Ruby i Tcl)
Spock (Groovy framework)
Yadda (obsługa języka Gherkin dla frameworków takich jak Jasmine (framework JavaScript))
Ogórek
Cucumber to bezpłatne narzędzie do specyfikacji plików wykonywalnych używane na całym świecie. Cucumber pozwala zespołom programistycznym opisywać, jak oprogramowanie powinno zachowywać się w postaci zwykłego tekstu. Tekst jest napisany w czytelnym dla biznesu języku specyficznym dla domeny i służy jako dokumentacja, testy automatyczne i pomoc w rozwoju, a wszystko to w jednym formacie. Z ogórkiem możesz używać ponad czterdziestu różnych języków (angielski, chiński itp.).
Ogórek - kluczowe cechy
Kluczowe cechy ogórka są następujące -
Ogórek może być używany do specyfikacji wykonywalnych, automatyzacji testów i żywej dokumentacji.
Cucumber współpracuje z Ruby, Java, NET, Flex lub aplikacjami internetowymi napisanymi w dowolnym języku.
Ogórek obsługuje bardziej zwięzłe testy w tabelach - podobnie do tego, co robi FIT.
Cucumber zrewolucjonizował cykl życia tworzenia oprogramowania, łącząc wymagania, automatyczne testy i dokumentację w jedną spójną: specyfikacje plików wykonywalnych w postaci zwykłego tekstu, które weryfikują oprogramowanie.
SpecFlow
SpecFlow to narzędzie BDD dla platformy .NET. SpecFlow to projekt typu open source. Kod źródłowy jest hostowany na GitHub.
SpecFlow używa składni Gherkin dla funkcji. Format Gherkin został wprowadzony przez Cucumber i jest również używany przez inne narzędzia. Język Gherkin jest utrzymywany jako projekt na GitHub -https://github.com/cucumber/gherkin
Zachowywać się
Zachowanie jest używane we frameworku Pythona.
Zachowanie działa z trzema typami plików przechowywanych w katalogu o nazwie „funkcje” -
pliki funkcji z twoimi scenariuszami zachowania.
Katalog „steps” z implementacjami kroków Pythona dla scenariuszy.
Opcjonalnie niektóre kontrole środowiskowe (kod do uruchomienia przed i po krokach, scenariuszach, funkcjach lub całym meczu strzeleckim).
Funkcje zachowania są napisane za pomocą Gherkin (z pewnymi modyfikacjami) i noszą nazwę „nazwa.funkcja”.
Tagi dołączone do funkcji i scenariusza są dostępne w funkcjach środowiska za pośrednictwem przekazanego do nich obiektu „feature” lub „scenario”. Na tych obiektach znajduje się atrybut o nazwie „tagi”, który jest listą dołączonych nazw tagów, w kolejności, w jakiej znajdują się w pliku właściwości.
Modyfikacje standardu Gherkin -
Behave może analizować standardowe pliki Gherkin i rozszerzyć Gherkin, aby zezwolić na słowa kluczowe składające się z małych liter, ponieważ czasami pozwalają one na bardziej czytelne specyfikacje funkcji
Sałata
Sałata to bardzo proste narzędzie BDD oparte na ogórku. Może wykonywać opisy funkcjonalne w postaci zwykłego tekstu jako testy automatyczne dla projektów Pythona. Sałata ma na celu wykonanie najczęstszych zadań na BDD.
Concordion
Concordion to narzędzie typu open source do automatyzacji specyfikacji na podstawie przykładów dla środowiska Java.
Chociaż podstawowe funkcje są proste, zaawansowany interfejs API platformy rozszerzeń umożliwia dodawanie funkcji, takich jak używanie arkuszy kalkulacyjnych programu Excel jako specyfikacji, dodawanie zrzutów ekranu do danych wyjściowych, wyświetlanie informacji o rejestrowaniu itp.
Concordion pozwala pisać specyfikacje w normalnym języku przy użyciu akapitów, tabel i odpowiedniej interpunkcji, a ustrukturyzowany język przy użyciu opcji Given / When / Then nie jest konieczne.
Concordion został przeniesiony do innych języków, w tym -
C # (Concordion.NET)
Python (PyConcordion)
Ruby (Ruby-Concordion)
Cucumber to narzędzie, które obsługuje specyfikacje wykonywalne, automatyzację testów i dokumentację życia.
Rozwój oparty na zachowaniu rozszerza specyfikację o przykład. Formalizuje również najlepsze praktyki Test-Driven Development, w szczególności perspektywę pracy z zewnątrz. Prace rozwojowe opierają się na wykonywalnych specyfikacjach.
Plik key features wykonywalnych specyfikacji są następujące -
Specyfikacje plików wykonywalnych to -
Wyprowadzone z przykładów, które reprezentują zachowania systemu.
Napisany przy współpracy wszystkich zaangażowanych w rozwój, w tym biznesu i interesariuszy.
Na podstawie kryterium akceptacji.
Testy akceptacyjne oparte na specyfikacjach plików wykonywalnych są zautomatyzowane.
Wspólny, wszechobecny język jest używany do pisania specyfikacji wykonywalnych i testów automatycznych, które -
W całym opracowaniu używana jest terminologia specyficzna dla domeny.
Wszyscy, w tym klienci i interesariusze, mówią w ten sam sposób o systemie, jego wymaganiach i implementacji.
Te same terminy są używane do omówienia systemu występującego w wymaganiach, dokumentach projektowych, kodzie, testach itp.
Każdy może przeczytać i zrozumieć wymagania oraz sposoby generowania większej liczby wymagań.
Zmiany można łatwo dostosować.
Dokumentacja na żywo jest utrzymywana.
Cucumber pomaga w tym procesie, ponieważ łączy wykonywalne specyfikacje z rzeczywistym kodem systemu i automatycznymi testami akceptacyjnymi.
Sposób, w jaki to robi, jest tak naprawdę zaprojektowany, aby zachęcić klientów i programistów do współpracy. Pozytywny wynik testu akceptacyjnego oznacza, że specyfikacja zachowania systemu, który reprezentuje, została poprawnie zaimplementowana.
Typowy test akceptacji ogórka
Rozważmy następujący przykład.
Feature − Sign up
Rejestracja powinna być szybka i przyjazna.
Scenariusz - pomyślna rejestracja
New użytkownicy powinni otrzymać e-mail z potwierdzeniem i zostać powitani osobiście.
Given Zdecydowałem się zarejestrować.
When Rejestruję się z ważnymi danymi.
Then Powinienem otrzymać e-mail z potwierdzeniem.
And Powinienem zobaczyć spersonalizowaną wiadomość powitalną.
Na tym przykładzie widzimy, że -
Testy akceptacyjne dotyczą Features.
Funkcje są wyjaśnione przez Scenarios.
Scenariusze składają się z Steps.
Specyfikacja jest napisana w języku naturalnym w postaci zwykłego pliku tekstowego, ale jest wykonywalna.
Praca z ogórkiem
Cucumber to narzędzie wiersza poleceń, które przetwarza pliki tekstowe zawierające funkcje poszukujące scenariuszy, które można wykonać w systemie. Zrozummy, jak działa ogórek.
Korzysta z wielu konwencji dotyczących nazw plików i ich lokalizacji (odpowiednie foldery), aby ułatwić rozpoczęcie.
Cucumber pozwala przechowywać specyfikacje, testy automatyczne i dokumentację w tym samym miejscu.
Każdy scenariusz jest listą kroków, które opisują warunki wstępne, działania i warunki końcowe scenariusza; jeśli każdy krok jest wykonywany bez błędu, scenariusz jest oznaczany jako zaliczony.
Pod koniec przebiegu Cucumber zgłosi, ile scenariuszy przeszło.
Jeśli coś się nie powiedzie, dostarcza informacji o tym, co się nie udało, aby deweloper mógł postępować.
W ogórku, Features, Scenarios, a kroki są napisane w języku o nazwie Gherkin.
Gherkin to zwykły tekst angielski (lub jeden z ponad 60 innych języków) ze strukturą. Korniszon jest łatwy do nauczenia, a jego struktura pozwala na pisanie przykładów w zwięzły sposób.
Cucumber wykonuje pliki, które zawierają wykonywalne specyfikacje zapisane w Gherkin.
Ogórek potrzebuje definicji kroku, aby przetłumaczyć kroki Gherkin jako zwykły tekst na akcje, które będą współdziałać z systemem.
Gdy Cucumber wykonuje krok w scenariuszu, będzie szukał pasującej definicji kroku do wykonania.
Definicja kroku to mały fragment kodu z dołączonym do niego wzorem.
Wzorzec jest używany do łączenia definicji kroku ze wszystkimi pasującymi krokami, a kod jest tym, co Cucumber wykona, gdy zobaczy krok Gherkin.
Każdemu krokowi towarzyszy definicja kroku.
Większość kroków będzie gromadzić dane wejściowe, a następnie delegować je do struktury specyficznej dla domeny aplikacji w celu wykonywania wywołań w tej strukturze.
Cucumber obsługuje kilkanaście różnych platform oprogramowania. Możesz wybrać implementację Cucumber, która działa dla Ciebie. Każda implementacja Cucumber zapewnia tę samą ogólną funkcjonalność, a także ma własną procedurę instalacji i funkcjonalność specyficzną dla platformy.
Mapowanie kroków i definicji kroków
Kluczem do Ogórka jest mapowanie między Krokami a Definicjami Kroków.
Wdrożenia Ogórek
Poniżej podano implementacje Cucumber.
|
Ruby / JRuby |
|
JRuby (przy użyciu Cucumber-JVM) |
|
Jawa |
|
Groovy |
|
.NET (przy użyciu SpecFlow) |
|
JavaScript |
|
|
JavaScript (przy użyciu Cucumber-JVM i Rhino) |
|
Clojure |
|
Gosu |
|
Lua |
|
PHP (używając Behat) |
|
Jython |
|
C ++ |
|
Tcl |
Integracja ramowa
Poniżej podano implementacje Framework.
|
Ruby on Rails |
|
Selen |
|
PicoContainer |
|
Spring Framework |
|
Watir |
Korniszon to język, którego używa się do pisania Features, Scenarios, and Steps. Celem Gherkin jest pomoc w pisaniu konkretnych wymagań.
Aby zrozumieć, co rozumiemy przez konkretne wymagania, rozważ następujący przykład -
Klienci powinni być chronieni przed wprowadzaniem nieprawidłowych danych karty kredytowej.
Jeśli klient wprowadzi numer karty kredytowej, który nie jest dokładnie 16-cyfrowy, przy próbie przesłania formularza powinien zostać ponownie wyświetlony z komunikatem o błędzie informującym o prawidłowej liczbie cyfr.
Ta ostatnia nie jest dwuznaczna, pozwala uniknąć błędów i jest znacznie bardziej testowalna.
Korniszon ma na celu stworzenie bardziej konkretnych wymagań. W Gherkin powyższy przykład wygląda następująco -
Feature
Informacja zwrotna przy wprowadzaniu nieprawidłowych danych karty kredytowej Feature Definition
Podczas testów użytkowników widzieliśmy wiele osób, które popełniają błędy Dokumentacja
Background True for all Scenarios Below
Given Wybrałem przedmiot do kupienia,
And Mam zamiar wprowadzić numer mojej karty kredytowej
Scenario - Zbyt krótki numer karty kredytowejScenario Definition
When Wpisuję numer karty, który ma mniej niż 16 cyfr
And wszystkie inne szczegóły są poprawne
And Przesyłam formularzSteps
Then formularz powinien zostać ponownie wyświetlony
And Powinien pojawić się komunikat informujący o prawidłowej liczbie cyfr
Format i składnia Gherkin
Pliki Gherkin są zwykłymi plikami tekstowymi i mają rozszerzenie .feature. Każdy wiersz, który nie jest pusty, musi zaczynać się słowem kluczowym Gherkin, po którym następuje dowolny tekst. Słowa kluczowe to -
Feature
Scenario
Biorąc pod uwagę, kiedy, wtedy i, ale (kroki)
Background
Zarys scenariusza
Examples
„” ”(Ciągi dokumentów)
| (Tabele danych)
@ (Tagi)
# (Komentarze)
*
Funkcja
Plik Featuresłowo kluczowe służy do opisywania funkcji oprogramowania i grupowania powiązanych scenariuszy. Funkcja ma trzy podstawowe elementy -
Słowo kluczowe - funkcja.
Nazwa funkcji podana w tym samym wierszu co słowo kluczowe Funkcja.
Opcjonalny (ale bardzo zalecany) opis, który może obejmować wiele wierszy, tj. Cały tekst między wierszem zawierającym słowo kluczowe Cecha a wierszem rozpoczynającym się od scenariusza, tła lub konspektu scenariusza.
Oprócz nazwy i opisu Funkcje zawierają listę scenariuszy lub ich zarysów oraz opcjonalne tło.
Zwykle nazywa się nazwę .featureplik, przyjmując nazwę funkcji, konwertując ją na małe litery i zastępując spacje podkreśleniami. Na przykład,
feedback_when_entering_invalid_credit_card_details.featureW celu zidentyfikowania funkcji w systemie można użyć tak zwanego „szablonu wprowadzania funkcji”.
Opisy
Niektóre części dokumentów Gherkin nie muszą zaczynać się słowem kluczowym.
W wierszach następujących po funkcji, scenariuszu, konspekcie scenariusza lub przykładach możesz napisać, co chcesz, o ile żadna linia nie zaczyna się od słowa kluczowego. To jest sposób na dołączenie opisów.
Scenariusz
Aby wyrazić zachowanie systemu, do każdej funkcji dołączasz jeden lub więcej scenariuszy. Typowe jest wyświetlenie od 5 do 20 scenariuszy na funkcję, aby całkowicie określić wszystkie zachowania wokół tej funkcji.
Scenariusze są zgodne z następującym wzorem -
Opisz kontekst początkowy
Opisz wydarzenie
Opisz oczekiwany wynik
Rozpoczynamy od kontekstu, opisujemy działanie i sprawdzamy wynik. Odbywa się to za pomocą kroków. Korniszon zawiera trzy słowa kluczowe opisujące każdy z kontekstów, działań i wyników jako kroki.
Given - Ustal kontekst
When - Wykonaj akcję
Then - Sprawdź wynik
Te słowa kluczowe zapewniają czytelność scenariusza.
Example
Scenario - Wypłać pieniądze z konta.
Given Mam na koncie 100 $.
When Proszę o 20 dolarów.
Then Należy wydać 20 dolarów.
Jeśli istnieje wiele plików Given lub When kroki jeden pod drugim, możesz użyć And lub But. Pozwalają szczegółowo określić scenariusze.
Example
Scenario - Spróbuj wypłaty za pomocą skradzionej karty.
Given Mam na koncie 100 $.
But moja karta jest nieważna.
When Proszę o 50 $.
Then moja karta nie powinna zostać zwrócona.
And Powinienem skontaktować się z bankiem.
Tworząc scenariusze, pamiętaj, że „każdy scenariusz musi mieć sens i być możliwy do wykonania niezależnie od innych scenariuszy”. To znaczy -
Warunek sukcesu jednego scenariusza nie może zależeć od tego, że wcześniej wykonano inny scenariusz.
Każdy scenariusz tworzy swój konkretny kontekst, wykonuje jedną rzecz i testuje wynik.
Takie scenariusze zapewniają następujące korzyści -
Testy będą prostsze i łatwiejsze do zrozumienia.
Możesz uruchomić tylko podzbiór swoich scenariuszy i nie musisz się martwić o zerwanie zestawu testowego.
W zależności od systemu możesz przeprowadzić testy równolegle, skracając czas potrzebny do wykonania wszystkich testów.
Zarys scenariusza
Jeśli musisz pisać scenariusze z kilkoma danymi wejściowymi lub wyjściowymi, możesz w końcu utworzyć kilka scenariuszy, które różnią się tylko wartościami. Rozwiązaniem jest użycie konspektu scenariusza. Aby napisać zarys scenariusza,
Zmienne w krokach konspektu scenariusza są oznaczone znakami <i>.
Różne wartości zmiennych podano jako przykłady w tabeli.
Example
Przypuśćmy, że piszesz funkcję dodawania dwóch liczb na kalkulatorze.
Feature - Dodaj.
Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input | output |
| 2+2 | 4 |
| 98+1 | 99 |
| 255+390 | 645 |Po sekcji konspektu scenariusza zawsze następuje jedna lub więcej sekcji przykładów, które są kontenerem dla tabeli. Tabela musi mieć wiersz nagłówka odpowiadający zmiennym w krokach konspektu scenariusza. Każdy z poniższych wierszy utworzy nowy scenariusz, wypełniając wartości zmiennych
SpecFlow to projekt typu open source. Kod źródłowy jest hostowany na GitHub. Pliki funkcji używane przez SpecFlow do przechowywania kryteriów akceptacji dla funkcji (przypadków użycia, historyjek użytkownika) w aplikacji są definiowane przy użyciu składni Gherkin.
Format Gherkin został wprowadzony przez Cucumber i jest również używany przez inne narzędzia. Język Gherkin jest utrzymywany jako projekt na GitHub -https://github.com/cucumber/gherkin
Elementy funkcji i SpecFlow
Kluczowe cechy elementów Feature to -
Element feature zapewnia nagłówek pliku funkcji. Element feature zawiera nazwę i ogólny opis odpowiedniej funkcji w aplikacji.
SpecFlow generuje klasę testów jednostkowych dla elementu funkcji, z nazwą klasy pochodzącą z nazwy funkcji.
SpecFlow generuje wykonywalne testy jednostkowe na podstawie scenariuszy, które reprezentują kryteria akceptacji.
Plik funkcji może zawierać wiele scenariuszy używanych do opisu testów akceptacyjnych funkcji.
Scenariusze mają nazwy i mogą składać się z wielu kroków scenariusza.
SpecFlow generuje metodę testów jednostkowych dla każdego scenariusza, z nazwą metody pochodzącą z nazwy scenariusza.
Wiele kroków scenariusza
Scenariusze mogą mieć wiele kroków scenariusza. Istnieją trzy rodzaje kroków, które definiują warunki wstępne, działania lub kroki weryfikacyjne, które składają się na test akceptacyjny.
Różne typy kroków zaczynają się od Given, When lub Then słowa kluczowe i kolejne kroki tego samego typu można łączyć za pomocą And i But słowa kluczowe.
Składnia Gherkin pozwala na dowolną kombinację tych trzech typów kroków, ale scenariusz zwykle ma odrębne bloki Given, When i Then sprawozdania.
Kroki scenariusza są definiowane za pomocą tekstu i mogą mieć dodatkową tabelę o nazwie DataTable lub tekst wielowierszowy o nazwie DocString arguments.
Kroki scenariusza są głównym sposobem wykonania dowolnego kodu niestandardowego w celu zautomatyzowania aplikacji.
SpecFlow generuje wywołanie wewnątrz metody testu jednostkowego dla każdego kroku scenariusza. Wywołanie jest wykonywane przez środowisko wykonawcze SpecFlow, które wykona definicję kroku dopasowaną do kroku scenariusza.
Dopasowanie odbywa się w czasie wykonywania, więc wygenerowane testy można skompilować i wykonać, nawet jeśli powiązanie nie zostało jeszcze zaimplementowane.
W krokach scenariusza można uwzględniać tabele i argumenty wielowierszowe. Są one używane w definicjach kroków i są przekazywane jako dodatkowe argumenty tabelowe lub łańcuchowe.
Tagi
Tagi to znaczniki, które można przypisać do funkcji i scenariuszy. Przypisanie etykiety do elementu jest równoważne przypisaniu etykiety do wszystkich scenariuszy w pliku funkcji. Nazwa tagu z początkowym @ oznacza tag.
Jeśli jest obsługiwany przez platformę testów jednostkowych, SpecFlow generuje kategorie z tagów.
Wygenerowana nazwa kategorii jest taka sama jak nazwa tagu, ale bez początkowego znaku @.
Testy do wykonania można filtrować i grupować przy użyciu tych kategorii testów jednostkowych. Na przykład możesz oznaczyć kluczowe testy tagiem @ważne, a następnie wykonywać je częściej.
Elementy tła
Element języka tła umożliwia określenie wspólnego warunku wstępnego dla wszystkich scenariuszy w pliku funkcji
Część pliku działająca w tle może zawierać jeden lub więcej kroków scenariusza, które są wykonywane przed innymi krokami scenariuszy.
SpecFlow generuje metodę z elementów tła, która jest wywoływana ze wszystkich testów jednostkowych wygenerowanych dla scenariuszy.
Zarysy scenariuszy
Zarysy scenariuszy mogą służyć do definiowania testów akceptacyjnych opartych na danych. Zarys scenariusza zawsze składa się ze specyfikacji szablonu scenariusza (scenariusz z symbolami zastępczymi danych używającymi składni <placeholder>) oraz zestawu przykładów, które zawierają wartości dla symboli zastępczych
Jeśli platforma testów jednostkowych to obsługuje, SpecFlow generuje testy oparte na wierszach na podstawie szkiców scenariusza.
W przeciwnym razie generuje sparametryzowaną metodę logiki testów jednostkowych dla zarysu scenariusza i indywidualną metodę testów jednostkowych dla każdego zestawu przykładów.
Aby zapewnić lepszą identyfikowalność, nazwy wygenerowanych metod testów jednostkowych pochodzą z tytułu schematu scenariusza i pierwszej wartości przykładów (pierwsza kolumna tabeli przykładów).
Dlatego dobrą praktyką jest wybranie unikalnego i opisowego parametru jako pierwszej kolumny w przykładowym zestawie.
Ponieważ składnia Gherkin wymaga, aby wszystkie przykładowe kolumny miały pasujące symbole zastępcze w zarysie scenariusza, możesz nawet wprowadzić dowolną kolumnę w przykładowych zestawach używanych do nazwania testów z większą czytelnością.
SpecFlow wykonuje podstawienie symbolu zastępczego jako oddzielną fazę przed dopasowaniem powiązań kroku.
Implementacja i parametry w powiązaniach kroków są zatem niezależne od tego, czy są wykonywane za pośrednictwem scenariusza bezpośredniego, czy konspektu scenariusza.
Pozwala to później określić dalsze przykłady w testach akceptacyjnych bez zmiany powiązań kroków.
Komentarze
Możesz dodawać linie komentarzy do plików funkcji w dowolnym miejscu, zaczynając wiersz od znaku #. Należy jednak uważać, ponieważ komentarze w specyfikacji mogą oznaczać, że kryteria akceptacji zostały określone nieprawidłowo. SpecFlow ignoruje wiersze komentarza.