BDD and ASP.NET MVC - Finding the Highway

About half a year ago, I started digging into unit testing. I made my way into TDD (or what I thought it was) and now I want to develop a MVC Application behavior-driven. The concept of acceptance testing (real end-to-end) is new to me, because my last project didn't run in a acceptance testable environment.

I started out by reading some good articles, notably Sanderson's http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/ and am backing up my MVC skills by reading his book on that topic.

I'm using SpecFlow and SimpleBrowser for end-to-end testing. Driving navigation through the navigation bar was a piece of cake, however I'm stuck now. I aim to implement user accounts for further creating articles and commenting. Driving the registration process gave me headaches. Given this feature file:

Feature: User accounts
    In order to customize and influence page content
    As a user
    I want to able to create an own user account

Scenario: Create a user
    Given  I am on the /Account/Create page
    When I fill out the registration formular as follows
    | NickName | EmailAddress                 |
    | test123  | test.address@test-server.com |
    And I click the "Create" button
    And I clicked the link in the authentication mail
    Then I should be on the root page
    And I should see the message "Welcome test123!"

I can't really figure out how to provide the necessary testing environment (a mail server in this example) and make the test less brittle (think of relabeling the "Create" button to "Submit"). Let alone weaving in a capture generator to prevent automatic user creation (oh irony) at a later time. Maybe I'm just thinking too much ahead, which you actually shouldn't in TDD, but there are times I'm just staring at t开发者_运维百科he screen and thinking about my next test.

---

Soo.. after that wall of text the actual question: How should I implement this kind of behavior?

• Stick to UI level tests and refactor as necessary for implementing capture logic
• Fall back to controller level testing
• Any other way you enlighten me on

---

I cannot say what is right or wrong here, so I'll just say what I do, since it works pretty well for me.

I use SpecFlow for testing my service layer. In ASP.net MVC, that would be the controller. As you mentioned, that kind of UI testing is very brittle, so I only recur to it when using some kind of advanced JavaScript UI.

That way, my testing stack looks something like this:

1. NUnit tests for more complex algorythms in the model
2. SpecFlow for testing the controller. This assures that the views receive what they should and that the models interact as intended.
3. QUnit tests for my JavaScript models, which I use mainly with Knockout JS (those two look like they were made for each other)
4. Manual acceptance tests (very coarse-grained and not too many of these), well documented
5. A few (very few) automated UI tests with WatiN for more advanced UIs

That said, about 75% of the tests written are for item 2 (SpecFlow) and 15% for item 3 (QUnit). That is just how it seems to work for me, but any suggestions are very welcome too.

---

I would not combine both the clicking on create button and clicking on the confirmation link in one test. I would finish the first test (clicking on create button) as I should see some message that says to check my email. If you want to test the rest of the behavior, you should create another test where given a confirmation URL and clicking on it, you should see the welcome page.