Most Frequently Asked Specflow Interview Questions and Answers:
Our previous Specflow Tutorial briefed on How to Generate Test Reports And Execute Selective tests.
In this tutorial, we will take a look at the most popular Specflow Interview Questions along with their answers.
Read through the Complete Specflow Training Series for an easy understanding of the concept. Specflow is a tool supporting BDD practices in the .NET framework. It’s an open-source framework hosted on GitHub. It aids in using ATDD (Acceptance Test Driver Development) for .NET.
Top Specflow Interview Questions and Answers
Enlisted below are the most popular Specflow Interview Questions with answers and examples for your easy understanding.
Q #1) What is the difference between the feature file and binding files?
Answer: Writing BDD tests in Specflow has 2 major components, namely
- Feature Files: Which contain the tests written as Scenarios in Domain Specific Language (DSL) and are essentially plain English files which are suitable and understandable for all the stakeholders of the project. In reality, they are the actual test files and are interpreted through the bindings or step definitions.
- Step Bindings: These code files are the actual intelligence logic behind test execution. Each step in a Scenario (which is a part of feature file) binds to a Step definition file which actually executes when the test is run.
Hence, a combination of both Feature files and Step definition or bindings make it possible for Specflow (or any other BDD) framework to run the tests.
Q #2) What is BDD and how is it different from TDD or ATDD?
Answer: All these three terms i.e. BDD, TDD, and ATDD are somewhat related to Test Driven Development in general but they are indeed different in a lot of ways
- TDD: TDD is basically creating tests from a developer’s perspective. In simple words, it’s a set of tests that a developer writes to make his code pass (or fail). It is essentially a technique to make your code fail until all the specific requirements get addressed. It basically follows a refactor cycle for code until the tests are all green.
- BDD: BDD closely relates to TDD but is more relevant from an “outside-in” perspective which actually means that BDD tests are more tied to business/product requirements and define the desired behavior of the system in the form of Scenarios. TDD in contrast deals at more granular Unit tests level. Also, BDD specifications are generally plain English text which is easy to understand and allows greater collaboration between all stakeholders of the project.
- ATDD: The focus of Acceptance Test-Driven Development is more from User’s acceptance perspective. These tests also define customer behavior but from integration or final product standpoint where a customer’s final Use case is converted into a test scenario and all the development work is focused to meet these requirements.
Q #3) What is contained in the auto-generated file for the Specflow feature?
Answer: Specflow code-behind files are auto-generated files with a “.cs” extension. These files have the binding logic from Steps to the actual Step definition.
Few points regarding the auto-generated files are:
- These files should not be modified or edited manually. Even if you try to do so, the changes do not get saved.
- After each and every change in the feature file, the compiler re-generates this file to capture updates.
Q #4) How are step bindings spread across different source files accessed?
Answer: Step binding files can be re-used even if they exist in separate source files & binding matching happens through a regex.
The step bindings files are essentially partial classes attributed by [Binding] attribute. This ensures that all step bindings are available globally and can be used with Scenario Steps in different or same feature files.
Q #5) How can ambiguous step binding implementations be resolved?
Answer: Specflow provides a mechanism to avoid ambiguous Step binding implementation using a concept called Scoped Bindings.
This is useful in scenarios where you have similar steps in Scenarios in same or different feature files and if you want to treat both the Steps differently.
In a normal scenario, as all the step matching happens through Regex, and it’s a greedy match, you’ll have to ensure that you write a slightly different text (so that they do not match the same implementation) for steps even though they impact readability.
Using Scoped Bindings, you can specify tags with a particular binding implementation or the entire binding file and ensure that the matching has an additional filter of category as well.
The steps that need to be followed are listed below:
a) Tag the scenario with a category using syntax – @Tag. Example: We are tagging the below scenario with tag – @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) Now use the same tag on the step binding which will ensure that in addition to regex match, the tag or category match also takes place (and ensures other steps fail to match this implementation even if regex match is successful)
In the above example, we want to scope the binding for the step. “And I have entered India as search keyword”, we will add the Scope attribute with Scoping parameter as the tag.
[Given(@"I have entered (.*) as search keyword"), Scope(Tag ="scopedBinding")]
public void GivenIHaveEnteredIndiaAsSearchKeyword(String searchString)
{
// step binding implementation
}
Similar to scoping with tag, it is also possible to have scoped bindings with Feature and Scenario titles.
Q #6) How can test context be stored while running different scenarios?
Answer: The test context can be stored using different approaches while running specflow tests and each approach has its pros and cons.
- Using ScenarioContext and FeatureContext: Think of FeatureContext and ScenarioContext as a global dictionary of key-value pairs and is accessible during feature execution and scenario execution respectively. The value field can store any type of Object and during retrieval, it needs to be cast into the object as desired.
- Using fields in binding files: This approach allows to share context across binding implementations in same and/or different binding files in the same namespace. It’s not different in maintaining state using class variables and can be set or retrieved across binding implementations as required.
- Using Specflow’s own DI framework: Specflow provides a context injection framework and can be used to pass context in the form of Simple POCO classes/objects. The context objects/classes can be injected through constructor fields and can be passed along different Step binding files.
See an Example below having 2 objects injected through constructor injection.
[Binding]
public class StepImplementationClass
{
private readonly Context1 _context1;
private readonly Context2 _context2;
public YoutubeSearchFeatureSteps(Context1 context1, Context2 context2)
{
_context1 = context1;
_context2 = context2;
}
}
Q #7) What are the limitations of Specflow or BDD in general?
Answer: BDD, as the name itself implies, defines the behavior with the application which is essentially converting use cases to test scenarios.
Hence the absence of stakeholders like a business, product and/or customers might impact the actual specifications that the developers are going to implement write tests for and hence it might result in not providing the actual value what it could have provided and had all the stakeholders were available while defining the scenarios.
Having said that most of the times pros outsmart the cons of BDD and is really a very helpful technique to test/validate the specifications. As it’s more or less language-agnostic since there are BDD frameworks available for almost all major programming languages like Cucumber for Java, RSpec for Ruby and Specflow for .NET.
Q #8) What are Step Argument Transformations?
Answer: Argument transformations as the name implies are nothing but transforming the scenario step.
Think of it as an extra layer of matching that happens before the actual step binding match happens, and it can be useful for transforming a different kind of user input rather than having different individual step implementations for the same type of input.
For any transformation step, the required attribute is StepArgumentTransformation
For Example, refer to the code sample below:
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
Referring to the code sample above, all three steps are related. But, if it had been through the usual regex matching, then you would be required to write three different step implementations.
With Step argument transformations in place, it is possible to transform the values and create a TimeStamp object from the specified parameters and return back to the original step implementation.
Let’s look at the implementation of the transformation.
[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
}
Thus, here we are transforming the scenario input to an intermediate value (like TimeStamp) and returning back the transformed value to the actual binding implementation as shown in the sample below.
[Given(@"I have entered (.*) into the timestamp to minute converter")]
public void GivenIHaveEnteredDaysIntoTheTimestampToMinuteConverter(TimeSpan tsTransformed)
{
// binding implementation
}
Notice, how the transformed value of type TimeSpan is now returned back to the actual Step binding implementation method.
Q #9) What are the different types of hooks provided by Specflow?
Answer:
Specflow provides a lot of custom Hooks or special events with which the event handlers (essentially methods/functions) can be bound to execute some setup/teardown logic.
Specflow provides the following hooks:
- BeforeFeature/AfterFeature: The event raised before and after feature starts and completes execution respectively.
- BeforeScenario/AfterScenario: The event raised before and after a scenario execution starts and completes respectively.
- BeforeScenarioBlock/AfterScenarioBlock: The event raised before and after a Scenario Block i.e. when any of the scenario blocks belonging to “Given”, “When” or “Then” starts or completes.
- BeforeStep/AfterStep: The event raised before and after each step of the scenario.
- BeforeTestRun/AfterTestRun: This event is raised only once during the entire test execution and once after the test execution completes.
It is important to note here that these events are raised by default, and are handled if and only if there are bindings provided for these hooks. Also, it is not mandatory to implement these hooks in pairs and every hook can exist independently of each other.
Q #10) How is ScenarioContext different from FeatureContext?
Answer: Both ScenarioContext and FeatureContext are static classes provided by the Specflow framework and are really helpful for performing tasks like passing info between bindings, getting important information like execution context of feature/scenario, etc.
Let’s see how both of them differ:
As the name implies ScenarioContext provides data or info at Scenario execution level while FeatureContext deals with things at the feature level.
In simplistic terms, anything stored in featureContext will be available to all the scenarios present in that feature file while ScenarioContext will be available to only just the bindings till the time scenario execution is in progress.
Q #11) How important is the order of given, when and then?
Answer: Specflow does not impose any restriction on the order of Given, When and Then. It’s more about the logical sequencing of a test scenario and any testing practice in general i.e. like in unit tests we typically follow three A’s standing for “Arrange, Act and Assert”.
So for specflow scenarios, there is no restriction on ordering and it also does not mandate that all the three sections should be present.
Often at times, the setup can be minimalistic and might not even be needed. Hence for those scenarios, you can simply skip the “Given” Block and start the scenario with the “When” block.
Q #12) What are ScenarioInfo and FeatureInfo?
Answer: SpecflowContext and FeatureContext further provide nested static classes namely ScenarioInfo and FeatureInfo.
ScenarioInfo gives access to information around the scenario that is currently being executed.
Some of the things that you can get to know with this class are given below:
- Title: The title of the scenario. Syntax: ScenarioContext.Current.ScenarioInfo.Title
- Tags: List of tags in the form of String[]. Syntax: ScenarioContext.Current.ScenarioInfo.Tags
Similar to ScenarioInfo, FeatureInfo also provides info pertaining to the current feature that is currently being executed.
In addition to title and tags, it also provides other useful things like what is the target Language for which feature code-behind the file is generating code, the Language details in which the Feature File is written, etc.
The syntax to obtain values for FeatureInfo remains the same as ScenarioInfo as below:
FeatureContext.Current.FeatureInfo
Q #13) Difference between Scenario Outline and Specflow tables.
Answer:
ScenarioOutline is basically a way to execute data-driven scenarios using Specflow where a list of inputs are provided in the Examples section in the scenario, and the scenario executes once each depending on the number of examples provided.
See a code sample below to understand it more clearly.
<strong>Scenario Outline:</strong> Youtube keyword search And I have entered <searchTerm> as search keyword When I press the search button Then I should be navigate to search results page <strong>Examples:</strong> | searchTerm | | India | | America
Tables are just means to supply tabular data with any step of the Scenario and is passed as Specflow table argument in the step implementation which can be later parsed to desired object type as required.
Please refer to the ‘bold’ section in the code sample below for more details:
Scenario: Pass data through Specflow tables for StudentInfo object Given I have entered following info for Student <strong>| FirstName | LastName | Age | YearOfBirth | | test | student | 20 | 1995 |</strong> When I press add Then i student should get added to database and entered info should be displayed on the screen
Similar to the Tags attribute – you can use any info provided by ScenarioInfo to control the execution flow of any step implementation.
Q #14) Controlling Test executing through ScenarioInfo.
Similar to scope bindings, which can allow adding an extra filter criterion while matching step definition through tags, you can also leverage controlling the test execution through the info provided with ScenarioInfo.
For Example, You have 2 scenarios with tags i.e. @tag1 and @tag2 and both contain the same step definition. Now you need to add custom logic depending on the scenario tags.
Thus in the step definition implementation, you can simply get all the tags associated with a scenario using ScenarioContext.Current.ScenarioInfo.Tags and check for the presence of a tag in the scenario being executed and decide which code you want to execute.
Refer to the code sample below for a better understanding:
[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
}
}
Similar to the Tags attribute – you can use any info provided by ScenarioInfo to control the execution flow of any step implementation.
Q #15) How can Specflow tests be executed in a continuous Integration kind of setup?
Answer:
With modern software development methodologies, continuous integration is a kind of a buzzword and is generally referred to as a set of practices, where every commit to the source code is considered as a candidate for production release.
Hence every commit essentially triggers different types of tests as quality gates to ensure that the change being committed does not cause any tests to fail or break.
Specflow – as we know, integrates very well with known frameworks like NUnit and MSUnit and can be run easily through the console applications of these testing frameworks given the DLL of the compiled project which has Specflow features and step implementations.
Hence, in order to achieve Specflow tests running as part of a continuous integration setup, the following is a list of high-level steps that can be followed:
#1) Compile the project containing the Specflow feature and step definition to get a compiled DLL.
#2) Now use NUnit or MSUnit console runners and provide the compiled DLL as the test source (These frameworks provide other capabilities as well as provide test filters depending on categories etc).
This step can be integrated with the Continuous Integration pipeline and can be executed through shell or DOS script with the CI tool like Jenkins or Bamboo etc.
#3) Once the test execution completes, the generated output report (which is specific to the console runner used), can be converted to a more readable HTML report using Specrun executable is available as part of NugetPackage.
This Step can also be executed through the command line which is provided out of the box by all the major continuous integration frameworks.
#4) Once the above step completes, we are ready with the report of the executed tests and summarized metrics of the test execution details.
We hope you enjoyed the entire range of tutorials in this Specflow training series. This series of tutorials would indeed be the best guide for any beginner or experienced person who wants to enrich his/her knowledge on Specflow!
PREV Tutorial OR Go Back to The FIRST Tutorial