Question

For example if I write Add A customer feature which might go like this:

Scenario: Add A customer
Given I am on the customer page
When I enter login name
then I press Add
And I should see the newly added customer confirmation message

I start to write the code in watin to open the browser and go to the customer page.
Which doesn’t exist at this point.

The questions are:
1) do I then jump into unit tests and write a unit test for the page that doesn’t exist? in MVC this would be a controller but in asp.net webforms it’s the same test that is in the step definition.
2) How does the unit test tie in with the step definition? Let’s say at the end of the project I have a load of features and a load of unit tests. Then one of the features starts failing if I looked at that how would I know which unit tests correspond to it? Or does this even matter?

I’m not sure if this is a best practice question or it’s whatever people feel is right.

Thanks in advance.

Answer 1

One of the cool things about specflow (and cucumber…) is that you can write the test before any page exists. So what I’d do is exactly what you planned to do.

1) Write a specflow test, which describes how you want to work with the page. Looks like you have that already.
2) Run the test. The first line will fail (Given I am on the customer page).

Now you have a choice. Do you just wan to write the code that fires up watin and navigates to the customer page? Fine, do that; then write the customer page (just enough so that the first line of the test passes).

Or, recognize that your test requires a customer page. There’s lots here to test: do all the data fields exist? Does the page do input validation correctly? If I post to the server, do I get the correct response? If I post to the server, does the DB get updated correctly? And so on. Some of these sound like unit tests (business logic that takes the form data and stores it in the DB); some sound like UI tests that would be good with SpecFlow (page details, validation) and some sound like integration tests (probably good with specflow).

Once you’ve written all those and they pass, go back to your original test, and get the second step to pass (I click…)

And so on.

To answer your second question, hopefully you’re running the unit tests and specflow tests often enough that if a test fails, it’s due to something you’ve done in the last few minutes. It shouldn’t be too hard to see what failed and match it to what you just did.

If you’re not running your tests that often, then well you should be.