How do I do unit & integration testing in a BDD style in ASP.NET MVC?

Question

I am learning Behavior Driven Development with ASP.NET MVC and, based on a post from Steve Sanderson, understand that BDD can mean, at least, the following test types: individua

Answer 1

Personally I use SpecFlow for building feature specific tests (i.e. "User creates new company record") where I'll sometimes (but not always) use Watin. For testing my respositories, or service classes, I'll use unit/integration tests with NUnit. Integration tests are for when I need to talk to the database during the test, unit is for when I simply run code in the target object under test without external interactions.

I would say that you don't need to use a BDD framework for your non UI tests. You can if you want, but there is no hard and fast rule on this. If you are going to do this, then I highly recommend creating more then one project for your tests. Keeping them split is a good idea, rather then mixing all the test into one project. You could name them:

MyProject.Tests.Features <-- For BDD SpecFlow tests.

MyProject.Tests.Integration <-- For tests that access an external resource i.e. database.

MyProject.Tests.Unit

If you're not wanting to use two BDD frameworks, you can still use MSTest/NUnit in a BDD way. For example, this blog article describes a nice naming convention which is close to BDD, but aimed at MSTest/NUnit unit tests. You could use this for your non SpecFlow tests when your testing things like repositories.

In summary - you don't have to use SpecFlow and MSpec in your testing, but if you do, then I recommend separate test projects.

Answer 2

I generally agree with what Jason posted.

You might want to divide your specs into two categories, system/integration and unit-level tests. You can describe both categories with any framework, but keep in mind that code-only approaches (NUnit, MSpec, etc.) require a business analyst to be capable of writing C#. SpecFlow/Gherkin can be a better approach if you want to involve analysts and users in writing specifications. Since the syntax and rules (Given, When, Then) are easy to understand and writing specifications from a user's perspective are easy to jot down after little training. It's all about bridging the communication gap and having users helping your team form the ubiquitous language of your domain.

I recommend having specifications support both working "outside in" and "inside out". You may start with an "outside in" SpecFlow specification written by the user/analyst/product owner and work your way from "unimplemented" towards "green" writing the actual code. The code supporting the feature is developed using TDD with a more technically oriented framework like MSpec (the "inside out" part).

Here's a repository that use MSpec for both unit and integration tests: https://github.com/agross/duplicatefinder.