top 15 popular specflow interview questions
가장 자주 묻는 Specflow 인터뷰 질문 및 답변 :
우리의 이전 Specflow 튜토리얼은 테스트 보고서를 생성하고 선택적 테스트를 실행하는 방법 .
이 자습서에서는 가장 인기있는 Specflow 인터뷰 질문에 대한 답변과 함께 살펴 보겠습니다.
읽기 완전한 Specflow 교육 시리즈 개념을 쉽게 이해할 수 있습니다. Specflow는 .NET 프레임 워크에서 BDD 방식을 지원하는 도구입니다. GitHub에서 호스팅되는 오픈 소스 프레임 워크입니다. .NET 용 ATDD (Acceptance Test Driver Development)를 사용하는 데 도움이됩니다.
Specflow 인터뷰 질문 및 답변
아래 목록은 가장 인기있는 Specflow 인터뷰 질문과 답변 및 예시입니다.
질문 # 1) 기능 파일과 바인딩 파일의 차이점은 무엇입니까?
대답: Specflow에서 BDD 테스트를 작성하는 데는 두 가지 주요 구성 요소가 있습니다.
- 기능 파일 : 여기에는 DSL (도메인 특정 언어)의 시나리오로 작성된 테스트가 포함되어 있으며 프로젝트의 모든 이해 당사자에게 적합하고 이해할 수있는 기본적으로 일반 영어 파일입니다. 실제로는 실제 테스트 파일이며 바인딩 또는 단계 정의를 통해 해석됩니다.
- 단계 바인딩 : 이 코드 파일은 테스트 실행 뒤에있는 실제 인텔리전스 논리입니다. 시나리오의 각 단계 (기능 파일의 일부)는 테스트가 실행될 때 실제로 실행되는 단계 정의 파일에 바인딩됩니다.
따라서 기능 파일과 단계 정의 또는 바인딩의 조합을 통해 Specflow (또는 다른 BDD) 프레임 워크가 테스트를 실행할 수 있습니다.
Q # 2) BDD는 무엇이며 TDD 또는 ATDD와 어떻게 다릅니 까?
대답: 이 세 가지 용어, 즉 BDD, TDD 및 ATDD는 일반적으로 테스트 주도 개발과 다소 관련이 있지만 실제로는 여러면에서 다릅니다.
- TDD : TDD는 기본적으로 개발자의 관점에서 테스트를 생성합니다. 간단히 말해서 개발자가 코드를 통과 (또는 실패)하기 위해 작성하는 일련의 테스트입니다. 본질적으로 모든 특정 요구 사항이 해결 될 때까지 코드를 실패하게 만드는 기술입니다. 기본적으로 테스트가 모두 녹색이 될 때까지 코드에 대한 리팩터링주기를 따릅니다.
- BDD : BDD는 TDD와 밀접한 관련이 있지만 실제로는 BDD 테스트가 비즈니스 / 제품 요구 사항에 더 많이 연결되어 있고 시나리오 형식으로 시스템의 원하는 동작을 정의한다는 것을 의미하는 '외부'관점에서 더 관련이 있습니다. 대조적으로 TDD는 더 세분화 된 단위 테스트 수준에서 처리합니다. 또한 BDD 사양은 일반적으로 이해하기 쉽고 프로젝트의 모든 이해 관계자가 더 많은 협력을 할 수있는 일반 영어 텍스트입니다.
- ATDD : 수용 테스트 주도 개발의 초점은 사용자의 수용 관점에서 더 많이 이루어집니다. 이러한 테스트는 또한 고객 행동을 정의하지만 고객의 최종 사용 사례가 테스트 시나리오로 변환되고 모든 개발 작업이 이러한 요구 사항을 충족하도록 집중되는 통합 또는 최종 제품 관점에서 정의됩니다.
Q # 3) Specflow 기능을 위해 자동 생성 된 파일에는 무엇이 포함되어 있습니까?
대답: Specflow 코드 숨김 파일은 확장자가 '.cs'인 자동 생성 파일입니다. 이러한 파일에는 단계에서 실제 단계 정의로의 바인딩 논리가 있습니다.
자동 생성 된 파일과 관련된 몇 가지 사항은 다음과 같습니다.
- 이러한 파일은 수동으로 수정하거나 편집해서는 안됩니다. 그렇게하려고해도 변경 사항이 저장되지 않습니다.
- 기능 파일이 변경 될 때마다 컴파일러는 업데이트를 캡처하기 위해이 파일을 다시 생성합니다.
Q # 4) 액세스되는 여러 소스 파일에 단계 바인딩이 어떻게 분산됩니까?
대답: 스텝 바인딩 파일은 별도의 소스 파일에 존재하더라도 재사용이 가능하며 바인딩 매칭은 정규식을 통해 이루어집니다.
단계 바인딩 파일은 기본적으로 (제본) 속성. 이렇게하면 모든 단계 바인딩이 전역 적으로 사용 가능하고 다른 또는 동일한 기능 파일에서 시나리오 단계와 함께 사용할 수 있습니다.
Q # 5) 모호한 단계 바인딩 구현을 어떻게 해결할 수 있습니까?
대답: Specflow는 다음과 같은 개념을 사용하여 모호한 단계 바인딩 구현을 방지하는 메커니즘을 제공합니다. 범위가 지정된 바인딩.
이는 동일하거나 다른 기능 파일의 시나리오에 유사한 단계가 있고 두 단계를 다르게 처리하려는 경우에 유용합니다.
일반적인 시나리오에서는 모든 단계 일치가 Regex를 통해 발생하고 탐욕스러운 일치이므로 단계에 영향을 주더라도 단계에 대해 약간 다른 텍스트 (동일한 구현과 일치하지 않도록)를 작성해야합니다. 가독성.
범위 바인딩을 사용하면 특정 바인딩 구현 또는 전체 바인딩 파일로 태그를 지정할 수 있으며 일치 항목에 카테고리의 추가 필터도 있는지 확인할 수 있습니다.
따라야하는 단계는 다음과 같습니다.
에) 구문을 사용하여 범주로 시나리오에 태그 지정 – @꼬리표. 예: 아래 시나리오에 태그 – @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 비) 이제 단계 바인딩에서 동일한 태그를 사용하여 정규식 일치 외에 태그 또는 카테고리 일치도 발생하도록합니다 (그리고 정규식 일치가 성공하더라도 다른 단계가이 구현과 일치하지 못하도록합니다).
위의 예에서는 단계의 바인딩 범위를 지정하려고합니다. “ 그리고 검색 키워드로 인도를 입력했습니다 ”, Scoping 매개 변수를 태그로 사용하여 Scope 속성을 추가합니다.
(Given(@'I have entered (.*) as search keyword'), Scope(Tag ='scopedBinding')) public void GivenIHaveEnteredIndiaAsSearchKeyword(String searchString) { // step binding implementation } 태그를 사용한 범위 지정과 유사하게 기능 및 시나리오 제목으로 범위가 지정된 바인딩을 가질 수도 있습니다.
Q # 6) 다른 시나리오를 실행하는 동안 테스트 컨텍스트를 어떻게 저장할 수 있습니까?
대답: 테스트 컨텍스트는 specflow 테스트를 실행하는 동안 다른 접근 방식을 사용하여 저장할 수 있으며 각 접근 방식에는 장단점이 있습니다.
- ScenarioContext 및 FeatureContext 사용 : FeatureContext 및 ScenarioContext를 키-값 쌍의 전역 사전으로 생각하고 기능 실행 및 시나리오 실행 중에 각각 액세스 할 수 있습니다. 값 필드는 모든 유형의 객체를 저장할 수 있으며 검색 중에 원하는대로 객체로 캐스팅해야합니다.
- 바인딩 파일에서 필드 사용 : 이 접근 방식을 사용하면 동일한 네임 스페이스의 동일한 및 / 또는 다른 바인딩 파일의 바인딩 구현간에 컨텍스트를 공유 할 수 있습니다. 클래스 변수를 사용하여 상태를 유지하는 데 차이가 없으며 필요에 따라 바인딩 구현 전체에서 설정하거나 검색 할 수 있습니다.
- Specflow의 고유 DI 프레임 워크 사용 : Specflow는 컨텍스트 주입 프레임 워크를 제공하며 Simple POCO 클래스 / 객체의 형태로 컨텍스트를 전달하는 데 사용할 수 있습니다. 컨텍스트 객체 / 클래스는 생성자 필드를 통해 삽입 될 수 있으며 다른 단계 바인딩 파일을 따라 전달 될 수 있습니다.
생성자 주입을 통해 주입 된 2 개의 객체가있는 아래 예제를 참조하십시오.
(Binding) public class StepImplementationClass { private readonly Context1 _context1; private readonly Context2 _context2; public YoutubeSearchFeatureSteps(Context1 context1, Context2 context2) { _context1 = context1; _context2 = context2; } } Q # 7) 일반적으로 Specflow 또는 BDD의 제한 사항은 무엇입니까?
대답: 이름 자체에서 알 수 있듯이 BDD는 기본적으로 사용 사례를 테스트 시나리오로 변환하는 애플리케이션의 동작을 정의합니다.
따라서 비즈니스, 제품 및 / 또는 고객과 같은 이해 관계자가 없으면 개발자가 쓰기 테스트를 구현할 실제 사양에 영향을 미칠 수 있으므로 제공 할 수있는 실제 값을 제공하지 못하고 모든 이해 관계자가 가질 수 있습니다. 시나리오를 정의하는 동안 사용할 수있었습니다.
대부분의 경우 전문가가 BDD의 단점을 능가하며 사양을 테스트 / 검증하는 데 매우 유용한 기술이라고 말했듯이. Java 용 Cucumber, Ruby 용 RSpec 및 .NET 용 Specflow와 같은 거의 모든 주요 프로그래밍 언어에 사용할 수있는 BDD 프레임 워크가 있기 때문에 언어에 구애받지 않습니다.
Q # 8) 단계 인수 변환이란 무엇입니까?
대답: 이름에서 알 수 있듯이 인수 변환은 시나리오 단계를 변환 할뿐입니다.
실제 단계 바인딩 일치가 발생하기 전에 발생하는 추가 일치 레이어로 생각하고 동일한 유형의 입력에 대해 다른 개별 단계 구현을 갖는 것보다 다른 유형의 사용자 입력을 변환하는 데 유용 할 수 있습니다.
모든 변환 단계에서 필수 속성은 다음과 같습니다. StepArgumentTransformation
예를 들어, 아래 코드 샘플을 참조하십시오.
예제가있는 유닉스의 grep 명령
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 위의 코드 샘플을 참조하면 세 단계가 모두 관련됩니다. 그러나 일반적인 정규식 일치를 거친 경우 세 가지 다른 단계 구현을 작성해야합니다.
단계 인수 변환을 사용하면 값을 변환하고 타임 스탬프 지정된 매개 변수에서 개체를 제거하고 원래 단계 구현으로 돌아갑니다.
변환의 구현을 살펴 보겠습니다.
(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 } 따라서 여기에서는 시나리오 입력을 중간 값 (예 : TimeStamp)으로 변환하고 변환 된 값을 아래 샘플과 같이 실제 바인딩 구현으로 되돌립니다.
(Given(@'I have entered (.*) into the timestamp to minute converter')) public void GivenIHaveEnteredDaysIntoTheTimestampToMinuteConverter(TimeSpan tsTransformed) { // binding implementation } TimeSpan 유형의 변환 된 값이 이제 실제 단계 바인딩 구현 메서드로 다시 반환되는 방법에 유의하십시오.
Q # 9) Specflow에서 제공하는 다양한 유형의 후크는 무엇입니까?
대답:
Specflow는 이벤트 핸들러 (본질적으로 메서드 / 함수)를 바인딩하여 일부 설정 / 해체 로직을 실행할 수있는 많은 사용자 지정 후크 또는 특수 이벤트를 제공합니다.
Specflow는 다음 후크를 제공합니다.
- BeforeFeature / AfterFeature : 기능이 시작되기 전과 후에 발생하는 이벤트는 각각 실행을 완료합니다.
- BeforeScenario / AfterScenario : 시나리오 실행이 시작되고 완료되기 전과 후에 발생한 이벤트입니다.
- BeforeScenarioBlock / AfterScenarioBlock : 시나리오 블록 전후에 발생하는 이벤트, 즉 'Given', 'When'또는 'Then'에 속하는 시나리오 블록이 시작되거나 완료 될 때 발생합니다.
- BeforeStep / AfterStep : 시나리오의 각 단계 전후에 발생한 이벤트입니다.
- BeforeTestRun / AfterTestRun : 이 이벤트는 전체 테스트 실행 중에 한 번만 그리고 테스트 실행이 완료된 후에 한 번만 발생합니다.
여기서 이러한 이벤트는 기본적으로 발생하며 이러한 후크에 대해 제공된 바인딩이있는 경우에만 처리된다는 점에 유의해야합니다. 또한 이러한 후크를 쌍으로 구현할 필요는 없으며 모든 후크는 서로 독립적으로 존재할 수 있습니다.
Q # 10) ScenarioContext는 FeatureContext와 어떻게 다릅니 까?
대답: ScenarioContext와 FeatureContext는 모두 Specflow 프레임 워크에서 제공하는 정적 클래스이며 바인딩 간의 정보 전달, 기능 / 시나리오의 실행 컨텍스트와 같은 중요한 정보 가져 오기 등과 같은 작업을 수행하는 데 정말 유용합니다.
둘 다 어떻게 다른지 살펴 보겠습니다.
이름에서 알 수 있듯이 ScenarioContext는 Scenario 실행 수준에서 데이터 또는 정보를 제공하는 반면 FeatureContext는 기능 수준에서 작업을 처리합니다.
간단히 말해서 featureContext에 저장된 모든 것은 해당 기능 파일에있는 모든 시나리오에서 사용할 수있는 반면 ScenarioContext는 시간 시나리오 실행이 진행될 때까지 바인딩에만 사용할 수 있습니다.
Q # 11) 주어진 순서는 언제, 그리고 어떻게 중요합니까?
대답: Specflow는 순서에 제한을 두지 않습니다. 주어진, 언제, 그리고 . 테스트 시나리오의 논리적 순서와 일반적인 테스트 관행에 관한 것입니다. 예를 들어 단위 테스트에서와 같이 일반적으로 세 가지 A를 따릅니다. ' 준비, 행동 및 주장 ”.
따라서 specflow 시나리오의 경우 주문에 제한이 없으며 세 섹션이 모두 있어야한다고 요구하지도 않습니다.
종종 설정은 최소화 될 수 있으며 필요하지 않을 수도 있습니다. 따라서 이러한 시나리오의 경우 ' 주어진 ”차단하고“ 언제 ' 블록.
Q # 12) ScenarioInfo와 FeatureInfo는 무엇입니까?
대답: SpecflowContext 및 FeatureContext는 중첩 된 정적 클래스 인 ScenarioInfo 및 FeatureInfo를 추가로 제공합니다.
ScenarioInfo는 현재 실행중인 시나리오에 대한 정보에 대한 액세스를 제공합니다.
이 클래스를 통해 알 수있는 몇 가지 사항은 다음과 같습니다.
- 표제: 시나리오의 제목입니다. 통사론: ScenarioContext.Current.ScenarioInfo.Title
- 태그 : 형식의 태그 목록 끈(). 통사론: ScenarioContext.Current.ScenarioInfo.Tags
에스 비슷한 ScenarioInfo, FeatureInfo 현재 실행중인 현재 기능과 관련된 정보도 제공합니다.
제목과 태그 외에도 파일 뒤에있는 기능 코드가 코드를 생성하는 대상 언어, 기능 파일이 작성된 언어 세부 정보 등과 같은 기타 유용한 정보도 제공합니다.
FeatureInfo에 대한 값을 얻기위한 구문은 아래와 같이 ScenarioInfo와 동일합니다.
FeatureContext.Current.FeatureInfo
컴퓨터를 청소하는 가장 좋은 프로그램은 무엇입니까
Q # 13) 시나리오 개요와 Specflow 테이블의 차이점.
대답:
시나리오 개요 기본적으로 입력 목록이 제공되는 Specflow를 사용하여 데이터 기반 시나리오를 실행하는 방법입니다. 예 섹션에서 제공되며 시나리오는 제공된 예제 수에 따라 각각 한 번씩 실행됩니다.
더 명확하게 이해하려면 아래 코드 샘플을 참조하십시오.
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 테이블은 시나리오의 모든 단계에 테이블 형식 데이터를 제공하는 수단 일 뿐이며 단계 구현에서 Specflow 테이블 인수로 전달되며 나중에 필요에 따라 원하는 객체 유형으로 구문 분석 할 수 있습니다.
자세한 내용은 아래 코드 샘플의 '굵게'섹션을 참조하십시오.
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 Tags 속성과 유사합니다. ScenarioInfo에서 제공하는 모든 정보를 사용하여 모든 단계 구현의 실행 흐름을 제어 할 수 있습니다.
문 # 14) ScenarioInfo를 통한 테스트 실행 제어
태그를 통해 단계 정의를 일치시키면서 추가 필터 기준을 추가 할 수있는 범위 바인딩과 유사하게 ScenarioInfo와 함께 제공된 정보를 통해 테스트 실행 제어를 활용할 수도 있습니다.
예를 들어 태그가있는 2 개의 시나리오 (예 : @ tag1 및 @ tag2)가 있으며 둘 다 동일한 단계 정의를 포함합니다. 이제 시나리오 태그에 따라 사용자 지정 논리를 추가해야합니다.
따라서 단계 정의 구현에서 다음을 사용하여 시나리오와 관련된 모든 태그를 간단히 가져올 수 있습니다. ScenarioContext.Current.ScenarioInfo.Tags 실행중인 시나리오에 태그가 있는지 확인하고 실행할 코드를 결정합니다.
더 나은 이해를 위해 아래 코드 샘플을 참조하십시오.
(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 } } Tags 속성과 유사합니다. ScenarioInfo에서 제공하는 모든 정보를 사용하여 모든 단계 구현의 실행 흐름을 제어 할 수 있습니다.
Q # 15) 지속적인 통합 설정에서 Specflow 테스트를 어떻게 실행할 수 있습니까?
대답:
최신 소프트웨어 개발 방법론에서 지속적인 통합은 일종의 유행어이며 일반적으로 일련의 관행이라고하며, 소스 코드에 대한 모든 커밋은 프로덕션 릴리스의 후보로 간주됩니다.
따라서 모든 커밋은 본질적으로 다른 유형의 테스트를 품질 게이트로 트리거하여 커밋되는 변경으로 인해 테스트가 실패하거나 중단되지 않도록합니다.
Specflow – 아시다시피, NUnit 및 MSUnit과 같은 알려진 프레임 워크와 매우 잘 통합되며 Specflow 기능 및 단계 구현이있는 컴파일 된 프로젝트의 DLL이 주어지면 이러한 테스트 프레임 워크의 콘솔 응용 프로그램을 통해 쉽게 실행할 수 있습니다.
따라서 지속적인 통합 설정의 일부로 실행되는 Specflow 테스트를 달성하기 위해 따라야 할 상위 수준 단계 목록은 다음과 같습니다.
#1) Specflow 기능 및 단계 정의가 포함 된 프로젝트를 컴파일하여 컴파일 된 DLL을 가져옵니다.
#두) 이제 NUnit 또는 MSUnit 콘솔 러너를 사용하고 컴파일 된 DLL을 테스트 소스로 제공합니다 (이러한 프레임 워크는 다른 기능을 제공 할뿐만 아니라 범주 등에 따라 테스트 필터를 제공합니다).
이 단계는 지속적 통합 파이프 라인과 통합 될 수 있으며 Jenkins 또는 Bamboo 등과 같은 CI 도구를 사용하여 쉘 또는 DOS 스크립트를 통해 실행할 수 있습니다.
#삼) 테스트 실행이 완료되면 생성 된 출력 보고서 (사용 된 콘솔 실행기에 해당)는 다음을 사용하여보다 읽기 쉬운 HTML 보고서로 변환 할 수 있습니다. Specrun 실행 파일은 NugetPackage의 일부로 제공됩니다.
이 단계는 모든 주요 연속 통합 프레임 워크에서 즉시 제공되는 명령 줄을 통해 실행할 수도 있습니다.
# 4) 위의 단계가 완료되면 실행 된 테스트 보고서와 테스트 실행 세부 정보의 요약 된 메트릭이 준비됩니다.
이 Specflow 교육 시리즈의 전체 자습서를 즐기 셨기를 바랍니다. 이 일련의 자습서는 Specflow에 대한 지식을 풍부하게하려는 초보자 또는 숙련 된 사람을위한 최고의 가이드가 될 것입니다!
이전 튜토리얼 또는돌아 가기 FIRST 튜토리얼