Should testers use the same tool as developers for BDD-style tests?

Question

I don’t have experience with BDD but after some research I see that it can be very useful in our project.

The idea is that developers want to create BDD-style tests (using SpecFlow) for their unit tests and our test team need some place to put automated web UI tests (using Selenium) as well as web services integration tests.

So question is: is it better to share the same objects between testers’ and developers’ tests or maybe separating those two worlds could get us e.g. better test management?

SpecFlow doesn’t seems to be a perfect solution for our testers (Robot framework or Fitnesse are taking into consideration) but it seems reasonable to use common tool and libraries for writing different kinds of tests.

Thanks,

Answer 1

I think you are going to find that the overlap between the two testing systems is likely to mean there is less to share than you expect.

First let's consider the development cycle under BDD. We start with a new feature definition, then develop a few scenarios and code to support that. In fact if we are doing this properly, each Specflow scenario is a business level test, and in order to drive the development of that single business level test, you've also probably developed a number of lower level unit level tests. I've heard this process described as a various things (including a "seven step process") but the important thing is that it is a cycle in a cycle, that you complete multiple Red Green Refactor unit test cycles in order to pass business level cycle turning the business level scenario from Red to Green.

So far nothing has necessarily tested the UI layer, particularly if we are working in MVC/MVVM or similarly tiered codebases. In fact this is how I advise my clients to work, there's no need to test whether clicking calls the command, we assume that we don't want to waste out time testing the framework we are working in, so we just call the command itself.

However you mention Selenium so I assume that you are using it to drive your interaction with the browser, so lets also assume that you want to do some testing at a UI level too. This code is crossing multiple domains (see Who's domain is it anyway) to give you high level concepts such as login and common processes that you now want to reuse. This code doesn't already exist and since its interacting with the browser doesn't tie in with your other code.

So I think you will find that you end up with two testing codebases, one used by unit tests and business level specifications to tests things in isolation, i.e. chunks of code held together with Mocks or just parts of the whole system.

The other incorporating Selenium test the interaction with a full system, its for integration testing and system testing.

Using SpecFlow specifications will still give you several really good things, such as common grammar to describe your system but if you decide to use it, I don't think it will be bound to the same code.