How to use spec flow to write automated acceptance test

Introduction to acceptance testing, gherkin and spec flow

Acceptance testing or functional testing is a test that verifies that the system meets the requirements. These tests, as one of the black box tests, have nothing to do with their internal execution. Acceptance tests are only used to verify that the system meets a requirement.

Now let's look at the following requirements for Web login features:

Feature:login in order to access my account as a user of the "
  website
  I want to log into the website

Scena Rio:logging in and valid credentials
  Given I am at the login page where
  I fill in the following form
  | field | Value |
  | Username | Xtrumanx |
  | Password | p@55w0rd |
  And I click the login button
  Then I should be at the home page

It's very readable, isn't it? The detailed requirements above are described in the Gherkin language. Gherkin is a domain-specific language that allows us to describe in detail how the application should be executed without explaining the specifics of the execution. Most of the above detailed requirements are made up of free text; There are only a few specific gherkin keywords: Feature, scenario, Given, when, and and then, others are free text, and the main document is how functional features are used.

Gherkin is a line based programming language in which each line in the scene is a step. The first step in a "Logging in with valid credentials" scenario is "Given I am at the login page." This step requires a concrete step definition so that our test runner can know how to complete the step. The step definition in Spec flow is actually a method with a variable that contains the specific text for that step. All step definition methods need to be included in a class that contains binding attributes.

[Binding]
Class Loginstepdefinitions
{
  [Given ("I am at the login page ')]] public
  void Giveniamattheloginpage ()
  c6/>//TODO
  }
}

The class and method names above are arbitrary. What really matters is the variables that are applied to classes and methods. Without them, Spec flow cannot confirm the binding relationship between the step definition method and the concrete step.

Now the remaining step definition is executed. And it's time for Watin and NUnit to play.

Watin is a browser-based automation tool. We will use it to open an IE instance, browse the URL, populate the table, click the button or link, and so on. At the same time, we will use NUnit to assert our expectations. Nevertheless, Watin and NUnit are not required. You can also use selenium for browser automation, and in fact, any unit test framework can be used to assert that you can even use Windows's own application Automation library, such as white, and then write automated acceptance tests for the appropriate Windows Forms or WPF applications.

Now let's try to create the actual acceptance test for a real application. For this article, we will use the instance program. Readers can get a copy from the repository here. The repository also contains a complete acceptance test project, but I recommend that you create your own acceptance test code by performing the remainder of this article.

Prerequisite

Spec flow is authorized by all supported Third-party test runs to run really heavy acceptance tests. As mentioned earlier, we will use NUnit to execute tests and Watin automation browsers. Here is an example of how to use the Watin Automation browser to perform Google queries for Watin (from the WAITN site).

[Test]
public void Searchforwatinongoogle ()
{
  using (var browser = new IE ("http://www.google.com"))
  {
    Browser. TextField (Find.byname ("Q")). TypeText ("Watin");
    Browser. Button (Find.byname ("btng")). Click ();

    Assert.istrue (browser. ContainsText ("Watin"));
  }

The test above creates a new IE instance and then passes Google's URL to the constructor and lets the browser jump to the Google page by the builder. Then look for a text box named "Q". The text box is where you want to enter the details of the query. When the text box is found, enter "Watin". Next, look for the button named "Btng" and click it. Finally, an assertion is made to determine that there is a "watin" on the page (can be anywhere on the page).

The code above gives us a quick demonstration of how simple it is to automate common tasks via Watin, which can be done on a browser such as filling out text boxes, clicking Buttons, and so on.

Next, you can create a new class library project for your acceptance test in Visual Studio. After you download NUnit and Watin, you will need to add the necessary DLLs to your acceptance test project. Add a Nunit.framework.dll reference to your acceptance test project from your NUnit download. For Watin, you will need to add two DLL references to your acceptance test project: Interop.SHDocVw.dll and WatiN.Core.dll.

It is worth mentioning that you can get NUnit and watin through the NuGet two projects. Both are easy to find in NuGet and can be automatically added to your project. If you have already used Nuge in your project, you can download these two items through it.

Get a spec flow from the Web site and install it on your system. Unlike NUnit and watin, you need to install spec flow in your system instead of simply copying DLL files. Spec flow comes with some tools, and each time you add an attribute file to your project, it creates the appropriate hidden code file. In addition, when you edit the feature file, it comes with syntax highlighting and other adjustments.

After the spec flow is successfully installed, check the installation directory (the default is Program Files). There are a bunch of DLL files in it, but you just need to add that reference to your project: TechTalk.SpecFlow.dll.