How to run specflow tests on a build Server?

Question

How do I run specflow tests using Nunit 2.6.1 on a build Server?

Also how do you maintainin and organize these tests to run successfully on the build server with multiple automation programmers coding seperate tests?

Answer 1

I will try to answer the second part of your question for now:

"how do you maintainin and organize these tests to run successfully on the build server with multiple automation programmers coding seperate tests?"

These kind of tests have a huge potential of being turned into a unmaintainable mess and here is why:

• steps are used to create contexts (for the scenario test)
• steps can be called from any scenario in any order

Due to these two simple facts, its easy to compare this model with procedural/structured programming. The scenario context is no different from some global variables and the steps are some methods that can be called at any time at any place.

What my team does to avoid a huge mess in the step files is to keep them as stupid as possible. Everything a step does is to parse and call services that will do the real meaningful job and hold the context of the current test. We call these services as 'xxxxDriver' (where xxxx is the domain object that we are dealing with).

a stupid example:

[Given("a customer named (.*)")]
public void GivenACustomer(string customerName)
{
  _customerDriver.CreateCustomer(customerName);
}


[Given("an empty schedule for the customer (.*)")]
public void GivenEmptySchedule(string customerName)
{
  var customer = _customerDriver.GetCustomer(customerName);
  _scheduleDriver.CreateForCustomer(customer);
}

The 'xxxxxDriver' will contain all repositories, webgateways, stubs, mocks or anything related with the related domain object. Another important detail is that if you inject these drivers in the step files, specflow will create an instance of it for each scenario and use it among all step files.

This was the best way we found to keep some consistency in the way we maintain and extend the steps without stepping in each other toes with a big team touching the same codebase. Another huge advantage is that it help us to find similar steps navigating through the usages of the methods in driver classes.

There's a clear example in the specflow codebase itself. (look at the drivers folder) https://github.com/techtalk/SpecFlow/tree/master/Tests/TechTalk.SpecFlow.Specs