Automate!

Let’s create our first automation scenario:

Right-click on the project’s name and select “Add -> New Item”

In the modal dialog’s left tree view of installed templates, select “SpecFlow”. This will expose the full list of SpecFlow file types.

For now, we’ll select “SpecFlow Feature File”.

Name your file and click “Add”.

I named my file “WikipediaTitleValidation.feature”.

In the generated scenario file, paste the following test:

So we have 3 scenarios, each validates a simple condition — that the title of the page is matching our expectations.

Rebuild the project and open Visual Studio’s Test Explorer:

So Visual Studio correctly identified 3 new unit tests, but we can’t really run them at this point.

We need to convert our BDD “language” into actual code.

To do that, we will need to create a “Steps” file, where we will “translate” each BDD sentence into a C# method.

Luckily, the SpecFlow integration with Visual Studio is superb.

All you need to do is to right-click on the open “feature” file, and select “Generate Steps Definition”

The following window will pop up:

SpecFlow is basically identifying all the steps in your feature file that do not have a backing code implementation.

We will want to keep all the steps checked, but in the future, you can be specific and choose the steps you want to auto-generate these steps for (for example, if you prefer to split some of the steps into a separate class — CommonSteps.cs for example)

Click the “Generate” button and you’ll be prompted to choose the location the newly created class will be saved.

Simply choose/navigate into your project’s folder, and click the “Save” button.

The default file name would be WikipediaTitleValidationSteps.cs but you can change it. I would suggest keeping this file name or choose a different convention, as long as you are consistent, you should be fine.

Let’s take a look at the generated file:

We can see that we have 2 methods, each representing a “step” in our test cases.

SpecFlow was smart enough to understand that we are using parameters in our steps, so the methods do take in a string parameter each.

Unfortunately, some of SpecFlow’s tooling hasn’t caught up with the most recent version of the library, so some of the auto-generated code does not follow the most up to date design patterns.

We will see the following error message:

This is very easy to fix. We can easily create a constructor and have the scenario context injected into it.

Let’s clean this up and make sure we follow the correct pattern:

So we removed the ScenarioContext’s Singelton/static references and used construction injection instead.

We can now start implementing our automation logic.

Since we have a very simplistic automation logic, I will show you the class in its final form:

We didn’t really need the ScenarioContext reference in our steps, we only needed it to gain access to the WebDriver instance we created earlier.

You can use the ScenarioContext to pass state between different states in the test. You need to remember that each step is being executed in its own WikipediaTitleValidationSteps instance, and in fact, these steps can be defined in multiple “Steps” classes.

The only recommended way to pass state between steps is by using the ScenarioContext object’s dictionary. Please try to avoid using static/globally accessible variables as much as possible.

If we run all of our tests in the test runner now, this is what we’ll see:

BUT WAIT:

You said that anyone can create BDD test cases. I see a lot of code here, what gives?

We’ll, in fact, anyone can create test cases, but each step will have to be “translated” into a proper C# method to be executed.

Over time, your automation project will evolve and grow a rich library of steps that can be reused and shared, and over time a lot of these pre-existing steps will be enough to create additional scenarios without additional coding effort.

Let’s put this theory to the test. Let’s pretend I’m the business owner of the project, and I jump into this unit test project to create a new scenario file: “WikipediaStockSymbolValidation.feature”:

Let’s take a look at how this file looks like in Visual Studio:

You can see that SpecFlow can already map the first step (navigate to a Wikipedia page) as a “known step” — and that step’s color is white.

The new step, where we want to verify the stock symbol is purple, hinting us that it’s unknown, or that there is no underlying code implementation for it.

At this point, you can run these tests, they will simply not run:

Let’s follow the steps we took earlier and create the missing step for this class.

Right-click anywhere on the file’s background, and select “Generate Step Definition”:

Note that only the “new” or “unidentified” steps are being presented here.

Save the file using the same naming convention as before, and here is how I implemented this logic:

After running all our tests, this is what we’ll see:

Not good… but expected. :-)

As it turns out “Apple” (the fruit) is not traded on the NASDAQ exchange, and “Google” is now “Alphabet Inc.”.

Let’s fix our scenarios:

Also note, that when you run all your tests right now, you will see 2 browser windows running at the same time — these scenarios will run in parallel. Pretty neat.

This is also a reminder of why it’s important not to share state between steps — using static or global state might cause the state to leak between the two (or more) windows. If sharing state is required — make sure you use the ScenarioContext.

When it’s all done, we’ll see the following result:

And we are done.

There isn’t a lot out there for C# developers looking to do UI automation and BDD, so I’m excited to share my knowledge with the world, hoping someone else will find it useful.

I hope you enjoyed this write up. If you would like to see more .NET automation articles let me know!