Menu

15 najpopularniejszych pytań do wywiadów Specflow

  • Główny
  • Inny
  • 15 najpopularniejszych pytań do wywiadów Specflow

top 15 popular specflow interview questions

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Najczęściej zadawane pytania i odpowiedzi do wywiadów Specflow:

Omówiliśmy nasz poprzedni samouczek Specflow Jak generować raporty z testów i przeprowadzać testy selektywne .

W tym samouczku przyjrzymy się najpopularniejszym pytaniom do wywiadów Specflow wraz z odpowiedziami.

Przeczytaj Kompletna seria szkoleń Specflow dla łatwego zrozumienia pojęcia. Specflow to narzędzie wspierające praktyki BDD w środowisku .NET. Jest to platforma typu open source hostowana na GitHub. Pomaga w korzystaniu z ATDD (Acceptance Test Driver Development) dla .NET.

najlepszy darmowy program do pobierania filmów z YouTube

Pytania do wywiadu Specflow

Najpopularniejsze pytania i odpowiedzi do wywiadów Specflow

Poniżej wymieniono najpopularniejsze pytania do wywiadów Specflow wraz z odpowiedziami i przykładami ułatwiającymi zrozumienie.

Pytanie nr 1) Jaka jest różnica między plikiem funkcji a plikami powiązań?

Odpowiedź: Pisanie testów BDD w Specflow ma 2 główne elementy, a mianowicie

  1. Pliki funkcji: Które zawierają testy napisane jako scenariusze w języku specyficznym dla domeny (DSL) i są zasadniczo zwykłymi plikami w języku angielskim, które są odpowiednie i zrozumiałe dla wszystkich interesariuszy projektu. W rzeczywistości są to rzeczywiste pliki testowe i są interpretowane przez powiązania lub definicje kroków.
  2. Wiązania krokowe: Te pliki kodu są rzeczywistą logiką inteligencji stojącą za wykonywaniem testów. Każdy krok w Scenariuszu (który jest częścią pliku funkcji) jest powiązany z plikiem definicji kroku, który jest faktycznie wykonywany po uruchomieniu testu.

W związku z tym kombinacja zarówno plików funkcji, jak i definicji Step lub powiązań umożliwia uruchomienie testów przez Specflow (lub dowolną inną platformę BDD).

P # 2) Co to jest BDD i czym różni się od TDD lub ATDD?

Odpowiedź: Wszystkie te trzy terminy, tj. BDD, TDD i ATDD, są w pewnym stopniu powiązane z programowaniem opartym na testach, ale w rzeczywistości różnią się pod wieloma względami

  1. TDD: TDD zasadniczo tworzy testy z perspektywy programisty. Krótko mówiąc, jest to zestaw testów, które programista pisze, aby jego kod przeszedł (lub zakończył się niepowodzeniem). Zasadniczo jest to technika powodująca niepowodzenie kodu, dopóki nie zostaną uwzględnione wszystkie określone wymagania. Zasadniczo przebiega zgodnie z cyklem refaktoryzacji kodu, dopóki wszystkie testy nie będą zielone.
  2. BDD: BDD jest ściśle powiązany z TDD, ale jest bardziej istotny z perspektywy „z zewnątrz w”, co w rzeczywistości oznacza, że ​​testy BDD są bardziej powiązane z wymaganiami biznesowymi / produktowymi i definiują pożądane zachowanie systemu w postaci Scenariuszy. Natomiast TDD zajmuje się bardziej szczegółowym poziomem testów jednostkowych. Ponadto specyfikacje BDD są na ogół prostym tekstem w języku angielskim, który jest łatwy do zrozumienia i umożliwia lepszą współpracę między wszystkimi interesariuszami projektu.
  3. ATDD: Rozwój oparty na testach akceptacji koncentruje się bardziej na perspektywie akceptacji użytkownika. Testy te definiują również zachowanie klienta, ale z punktu widzenia integracji lub produktu końcowego, gdzie ostateczny przypadek użycia klienta jest przekształcany w scenariusz testowy, a cała praca programistyczna jest skoncentrowana na spełnieniu tych wymagań.

P # 3) Co zawiera automatycznie wygenerowany plik dla funkcji Specflow?

Odpowiedź: Pliki związane z kodem Specflow to generowane automatycznie pliki z rozszerzeniem „.cs”. Te pliki mają logikę powiązań od Steps do rzeczywistej definicji Step.

Kilka punktów dotyczących automatycznie generowanych plików to:

  • Tych plików nie należy modyfikować ani edytować ręcznie. Nawet jeśli spróbujesz to zrobić, zmiany nie zostaną zapisane.
  • Po każdej zmianie w pliku funkcji kompilator ponownie generuje ten plik w celu przechwycenia aktualizacji.

P # 4) W jaki sposób jest uzyskiwany dostęp do powiązań krokowych w różnych plikach źródłowych?

Odpowiedź: Pliki powiązań krokowych można ponownie wykorzystać, nawet jeśli istnieją w oddzielnych plikach źródłowych, a dopasowywanie powiązań odbywa się za pośrednictwem wyrażenia regularnego.

Pliki powiązań kroków są zasadniczo częściowymi klasami przypisywanymi przez (Wiążący) atrybut. Gwarantuje to, że wszystkie powiązania kroków są dostępne globalnie i mogą być używane z krokami scenariusza w różnych lub tych samych plikach funkcji.

P # 5) Jak można rozwiązać niejednoznaczne implementacje powiązań krokowych?

Odpowiedź: Specflow zapewnia mechanizm pozwalający uniknąć niejednoznacznej implementacji powiązania Step przy użyciu koncepcji o nazwie Scoped Bindings.

Jest to przydatne w scenariuszach, w których masz podobne kroki w scenariuszach w tych samych lub różnych plikach funkcji i jeśli chcesz traktować oba kroki inaczej.

W normalnym scenariuszu, ponieważ dopasowywanie wszystkich kroków odbywa się za pośrednictwem Regex i jest to chciwe dopasowanie, musisz upewnić się, że napiszesz nieco inny tekst (tak, aby nie pasowały do ​​tej samej implementacji) dla kroków, nawet jeśli mają one wpływ czytelność.

Korzystając z powiązań w zakresie, można określić tagi z określoną implementacją powiązania lub całym plikiem powiązania i upewnić się, że dopasowywanie ma również dodatkowy filtr kategorii.

Kroki, które należy wykonać, są wymienione poniżej:

do) Oznacz scenariusz kategorią za pomocą składni - @Etykietka. Przykład: Otagujemy poniższy scenariusz tagiem - @scopedBinding

@scopedBinding Scenario: Youtube should search for the given keyword and should navigate to search results page Given I have navigated to youtube website And I have entered India as search keyword When I press the search button Then I should be navigate to search results page

b) Teraz użyj tego samego tagu w powiązaniu kroku, co zapewni, że oprócz dopasowania wyrażenia regularnego, nastąpi również dopasowanie tagu lub kategorii (i zapewni, że inne kroki nie będą pasować do tej implementacji, nawet jeśli dopasowanie wyrażenia regularnego się powiedzie)

W powyższym przykładzie chcemy określić zakres wiązania dla kroku. „ I wprowadziłem Indie jako słowo kluczowe wyszukiwania ”, Dodamy atrybut Scope z parametrem Scoping jako tag.

(Given(@'I have entered (.*) as search keyword'), Scope(Tag ='scopedBinding')) public void GivenIHaveEnteredIndiaAsSearchKeyword(String searchString) { // step binding implementation }

Podobnie jak w przypadku określania zakresu za pomocą znacznika, możliwe jest również tworzenie powiązań w zakresie z tytułami funkcji i scenariuszy.

P # 6) W jaki sposób można przechowywać kontekst testowy podczas uruchamiania różnych scenariuszy?

Odpowiedź: Kontekst testowy można przechowywać przy użyciu różnych podejść podczas przeprowadzania testów przepływu specyfikacji, a każde podejście ma swoje wady i zalety.

  1. Korzystanie z ScenarioContext i FeatureContext: Pomyśl o FeatureContext i ScenarioContext jako o globalnym słowniku par klucz-wartość i jest dostępny odpowiednio podczas wykonywania funkcji i wykonywania scenariusza. Pole wartości może przechowywać dowolny typ obiektu i podczas pobierania musi być rzutowane na obiekt zgodnie z potrzebami.
  2. Korzystanie z pól w plikach wiążących: Takie podejście umożliwia udostępnianie kontekstu między implementacjami powiązań w tych samych i / lub różnych plikach powiązań w tej samej przestrzeni nazw. Utrzymywanie stanu przy użyciu zmiennych klas nie różni się niczym i można je ustawiać lub pobierać w zależności od potrzeb implementacji powiązań.
  3. Korzystanie z własnej struktury DI Specflow: Specflow zapewnia strukturę iniekcji kontekstu i może być używany do przekazywania kontekstu w postaci klas / obiektów Simple POCO. Obiekty / klasy kontekstu mogą być wstrzykiwane za pośrednictwem pól konstruktora i mogą być przekazywane wraz z różnymi plikami powiązań Step.

Zobacz poniższy przykład z 2 obiektami wstrzykniętymi przez wstrzyknięcie konstruktora.

jak dodać repozytorium svn w eclipse
(Binding) public class StepImplementationClass { private readonly Context1 _context1; private readonly Context2 _context2; public YoutubeSearchFeatureSteps(Context1 context1, Context2 context2) { _context1 = context1; _context2 = context2; } }

P # 7) Jakie są ogólne ograniczenia Specflow lub BDD?

Odpowiedź: BDD, jak sama nazwa wskazuje, definiuje zachowanie z aplikacją, która zasadniczo konwertuje przypadki użycia na scenariusze testowe.

W związku z tym brak interesariuszy, takich jak firma, produkt i / lub klienci, może wpłynąć na rzeczywiste specyfikacje, dla których programiści zamierzają wdrożyć testy pisania, a zatem może skutkować niedostarczeniem rzeczywistej wartości, jaką mógł zapewnić i mieć wszystkich interesariuszy były dostępne podczas definiowania scenariuszy.

Powiedziawszy, że w większości przypadków profesjonaliści przechytrzają wady BDD i jest to naprawdę bardzo pomocna technika testowania / walidacji specyfikacji. Ponieważ jest mniej lub bardziej niezależny od języka, ponieważ istnieją frameworki BDD dostępne dla prawie wszystkich głównych języków programowania, takich jak Cucumber dla Java, RSpec dla Ruby i Specflow dla .NET.

P # 8) Co to są transformacje argumentów krokowych?

Odpowiedź: Transformacje argumentów, jak sama nazwa wskazuje, to nic innego jak przekształcenie kroku scenariusza.

Pomyśl o tym jako o dodatkowej warstwie dopasowania, która ma miejsce przed rzeczywistym dopasowaniem powiązania kroku, i może być przydatna do przekształcania innego rodzaju danych wejściowych użytkownika, zamiast mieć różne implementacje poszczególnych kroków dla tego samego typu danych wejściowych.

Dla każdego kroku transformacji wymagany atrybut to StepArgumentTransformation

Na przykład zapoznaj się z przykładowym kodem poniżej:

Given I have entered 50 days into the timestamp to minute converter Given I have entered 1 day, 2 hours, 3 minutes into the timestamp to minute converter Given I have entered 1 day, 1 hour, 1 minute, 30 seconds into the timestamp to minute converter

Odnosząc się do powyższego przykładu kodu, wszystkie trzy kroki są powiązane. Ale gdyby było to zwykłe dopasowywanie wyrażeń regularnych, musiałbyś napisać trzy różne implementacje krokowe.

Dzięki przekształceniom argumentów Step można przekształcić wartości i utworzyć plik Znak czasu obiektu z określonych parametrów i wróć do pierwotnej implementacji kroku.

Przyjrzyjmy się realizacji transformacji.

(StepArgumentTransformation(@'(?:(d*) day(?:s)?(?:, )?)?(?:(d*) hour(?:s)?(?:, )?)?(?:(d*) minute(?:s)?(?:, )?)?(?:(d*) second(?:s)?(?:, )?)?')) public TimeSpan convertToTimeSpan(String days, String hours, String minutes, String seconds) { // timestamp conversion logic }

W ten sposób przekształcamy dane wejściowe scenariusza na wartość pośrednią (taką jak TimeStamp) i zwracamy przekształconą wartość do rzeczywistej implementacji powiązania, jak pokazano w poniższym przykładzie.

(Given(@'I have entered (.*) into the timestamp to minute converter')) public void GivenIHaveEnteredDaysIntoTheTimestampToMinuteConverter(TimeSpan tsTransformed) { // binding implementation }

Zwróć uwagę, jak przekształcona wartość typu TimeSpan jest teraz zwracana z powrotem do rzeczywistej metody implementacji powiązania Step.

P # 9) Jakie są różne typy haków zapewniane przez Specflow?

Odpowiedź:

Specflow zapewnia wiele niestandardowych hooków lub zdarzeń specjalnych, za pomocą których programy obsługi zdarzeń (zasadniczo metody / funkcje) mogą być powiązane z wykonywaniem pewnej logiki konfiguracji / porzucenia.

Specflow udostępnia następujące haki:

  1. PrzedFeature / AfterFeature: Zdarzenie wywołane przed i po funkcji rozpoczyna się i kończy wykonywanie odpowiednio.
  2. BeforeScenario / AfterScenario: Zdarzenie wywoływane przed i po wykonaniu scenariusza odpowiednio się rozpoczyna i kończy.
  3. BeforeScenarioBlock / AfterScenarioBlock: Zdarzenie wywołane przed i po bloku scenariusza, tj. Kiedy dowolny ze scenariuszy bloków należących do „Given”, „When” lub „Then” rozpoczyna się lub kończy.
  4. BeforeStep / AfterStep: Zdarzenie wywołane przed i po każdym kroku scenariusza.
  5. Przed uruchomieniem testowym / Po uruchomieniu testu: To zdarzenie jest wywoływane tylko raz podczas całego wykonywania testu i raz po zakończeniu wykonywania testu.

Należy tu zauważyć, że te zdarzenia są wywoływane domyślnie i są obsługiwane wtedy i tylko wtedy, gdy istnieją powiązania dla tych punktów zaczepienia. Ponadto nie jest obowiązkowe stosowanie tych haków w parach, a każdy hak może istnieć niezależnie od siebie.

P # 10) Czym różni się ScenarioContext od FeatureContext?

Odpowiedź: Zarówno ScenarioContext, jak i FeatureContext są klasami statycznymi dostarczanymi przez platformę Specflow i są bardzo pomocne przy wykonywaniu zadań, takich jak przekazywanie informacji między powiązaniami, uzyskiwanie ważnych informacji, takich jak kontekst wykonania funkcji / scenariusza itp.

Zobaczmy, czym się różnią:

Jak sama nazwa wskazuje, ScenarioContext dostarcza dane lub informacje na poziomie wykonania scenariusza, podczas gdy FeatureContext zajmuje się sprawami na poziomie funkcji.

Mówiąc prościej, wszystko, co jest przechowywane w featureContext, będzie dostępne dla wszystkich scenariuszy obecnych w tym pliku funkcji, podczas gdy ScenarioContext będzie dostępne tylko dla powiązań do czasu wykonania scenariusza.

Q # 11) Jak ważna jest kolejność podana, kiedy i kiedy?

Odpowiedź: Specflow nie nakłada żadnych ograniczeń na kolejność Biorąc pod uwagę, kiedy i wtedy . Chodzi bardziej o logiczne sekwencjonowanie scenariusza testowego i ogólnie o wszelkich praktykach testowych, np. Podobnie jak w testach jednostkowych, zazwyczaj kierujemy się trzema A, ' Organizuj, działaj i potwierdzaj ”.

Tak więc w przypadku scenariuszy specflow nie ma ograniczeń dotyczących zamawiania, a także nie nakazuje, aby wszystkie trzy sekcje były obecne.

Często konfiguracja może być minimalistyczna i może nawet nie być potrzebna. Dlatego w tych scenariuszach możesz po prostu pominąć „ Dany „Zablokuj i rozpocznij scenariusz z„ Kiedy ”Blok.

P # 12) Co to są informacje o scenariuszu i informacje o funkcji?

Odpowiedź: SpecflowContext i FeatureContext dodatkowo zapewniają zagnieżdżone klasy statyczne, mianowicie ScenarioInfo i FeatureInfo.
ScenarioInfo zapewnia dostęp do informacji dotyczących aktualnie wykonywanego scenariusza.

Oto kilka rzeczy, które możesz poznać na tej klasie:

  1. Tytuł: Tytuł scenariusza. Składnia: ScenarioContext.Current.ScenarioInfo.Title
  2. Tagi: Lista tagów w postaci Strunowy(). Składnia: ScenarioContext.Current.ScenarioInfo.Tags

S podobny do ScenarioInfo, FeatureInfo zawiera również informacje dotyczące aktualnie wykonywanej funkcji.

Oprócz tytułu i tagów zapewnia także inne przydatne rzeczy, takie jak język docelowy, dla którego kod funkcji za plikiem generuje kod, szczegóły języka, w którym zapisany jest plik funkcji itp.

Składnia służąca do uzyskiwania wartości dla FeatureInfo pozostaje taka sama jak w ScenarioInfo, jak poniżej:
FeatureContext.Current.FeatureInfo

Q # 13) Różnica między Zarys scenariusza a tabelami Specflow.

Odpowiedź:

ScenarioOutline jest w zasadzie sposobem na wykonywanie scenariuszy opartych na danych przy użyciu Specflow, w którym lista danych wejściowych znajduje się w Przykłady w scenariuszu, a scenariusz jest wykonywany raz, w zależności od liczby dostarczonych przykładów.

Zobacz przykładowy kod poniżej, aby lepiej go zrozumieć.

Scenario Outline: Youtube keyword search And I have entered as search keyword When I press the search button Then I should be navigate to search results page Examples: | searchTerm | | India | | America

Tabele służą jedynie do dostarczania danych tabelarycznych w dowolnym kroku Scenariusza i są przekazywane jako argument tabeli Specflow w implementacji kroku, który można później przeanalizować do żądanego typu obiektu zgodnie z wymaganiami.

Więcej informacji można znaleźć w sekcji „pogrubionej” w poniższym przykładzie kodu:

Scenario: Pass data through Specflow tables for StudentInfo object Given I have entered following info for Student | FirstName | LastName | Age | YearOfBirth | | test | student | 20 | 1995 | When I press add Then i student should get added to database and entered info should be displayed on the screen

Podobnie jak w przypadku atrybutu Tags - możesz użyć dowolnych informacji dostarczonych przez ScenarioInfo, aby kontrolować przepływ wykonywania dowolnej implementacji kroku.

Pytanie nr 14) Kontrolowanie wykonywania testu przez ScenarioInfo.

Podobnie jak w przypadku powiązań zakresu, które mogą umożliwiać dodanie dodatkowego kryterium filtru podczas dopasowywania definicji kroku za pomocą tagów, można również wykorzystać kontrolę wykonywania testu za pomocą informacji dostarczonych ze ScenarioInfo.

Na przykład, Masz 2 scenariusze z tagami, tj. @ Tag1 i @ tag2, i oba zawierają tę samą definicję kroku. Teraz musisz dodać niestandardową logikę w zależności od tagów scenariusza.

Dlatego w implementacji definicji kroku można po prostu pobrać wszystkie tagi skojarzone ze scenariuszem przy użyciu ScenarioContext.Current.ScenarioInfo.Tags i sprawdź obecność tagu w wykonywanym scenariuszu i zdecyduj, który kod chcesz wykonać.

Zapoznaj się z przykładowym kodem poniżej, aby lepiej zrozumieć:

(When(@'I press add')) public void WhenIPressAdd() { String() tags = ScenarioContext.Current.ScenarioInfo.Tags; String expectedTag = 'tag1'; if(tags.Any(s => s == expectedTag)) { // do something } else { // do something else } }

Podobnie jak w przypadku atrybutu Tags - możesz użyć dowolnych informacji dostarczonych przez ScenarioInfo, aby kontrolować przepływ wykonywania dowolnej implementacji kroku.

P # 15) Jak można wykonywać testy Specflow w konfiguracji typu ciągłej integracji?

programy do wywiadów java dla odświeżaczy pdf

Odpowiedź:

W przypadku nowoczesnych metodologii tworzenia oprogramowania, ciągła integracja jest rodzajem modnego hasła i jest ogólnie określana jako zbiór praktyk, w których każde zobowiązanie do wprowadzenia kodu źródłowego jest traktowane jako kandydat do wydania produkcyjnego.

Dlatego każde zatwierdzenie zasadniczo wyzwala różne typy testów jako bramki jakości, aby zapewnić, że wprowadzana zmiana nie spowoduje niepowodzenia lub przerwania testów.

Specflow - jak wiemy, bardzo dobrze integruje się ze znanymi frameworkami, takimi jak NUnit i MSUnit i może być łatwo uruchamiany przez aplikacje konsolowe tych frameworków testowych, biorąc pod uwagę bibliotekę DLL skompilowanego projektu, która ma funkcje Specflow i implementacje krokowe.

Dlatego w celu uzyskania testów Specflow działających w ramach konfiguracji ciągłej integracji, poniżej znajduje się lista kroków wysokiego poziomu, które można wykonać:

# 1) Skompiluj projekt zawierający funkcję Specflow i definicję kroku, aby uzyskać skompilowaną bibliotekę DLL.

#dwa) Teraz użyj programów uruchamiających konsole NUnit lub MSUnit i zapewnij skompilowaną bibliotekę DLL jako źródło testowe (te struktury zapewniają inne możliwości, a także zapewniają filtry testowe w zależności od kategorii itp.).

Ten krok można zintegrować z potokiem ciągłej integracji i wykonać za pomocą skryptu powłoki lub DOS za pomocą narzędzia CI, takiego jak Jenkins lub Bamboo itp.

# 3) Po zakończeniu testu wygenerowany raport wyjściowy (który jest specyficzny dla używanego programu uruchamiającego konsolę) można przekonwertować na bardziej czytelny raport HTML za pomocą Specrun wykonywalny jest dostępny jako część pakietu NugetPackage.

Ten krok można również wykonać za pomocą wiersza poleceń, który jest dostarczany po wyjęciu z pudełka przez wszystkie główne platformy ciągłej integracji.

# 4) Po zakończeniu powyższego kroku jesteśmy gotowi z raportem z wykonanych testów i podsumowaniem metryk szczegółów wykonania testów.

Mamy nadzieję, że spodobał Ci się cały zakres samouczków w tej serii szkoleń Specflow. Ta seria samouczków byłaby rzeczywiście najlepszym przewodnikiem dla każdej początkującej lub doświadczonej osoby, która chce wzbogacić swoją wiedzę na temat Specflow!

POPRZEDNIA samouczek LUBWróć do PIERWSZY samouczek

rekomendowane lektury

^