When writing UI tests, how does one test one thing that lies at the end of a long sequence?

I just got started running UI tests against my ASP.NET MVC application using WatiN. It's a great tool and really intuitive, but I find myself wondering what belongs in an individual test.

I found a number of people suggesting that these tests should be treated like unit tests and as such there should be no expectations on order or side effects.

I run into problems when the user story assumes that the user has completed a series of steps before completing the activity I want to test.

Some examples...

1. A user must register, log out, and enter the wrong password 3 times to veri开发者_运维知识库fy that the system won't let them log in again with the right password

2. A user must register, add some foos, add some bars, submit a form that allows them to select among their foos and bars, and see their submission on another page

With unit tests, I can use mocking to take care of the prerequisite tasks.

What are some good ways of handling this scenario such that I can avoid writing individual tests that go through the same prerequisite steps yet have tests that complete reliably every time?

Hey.
I would split integration tests and story acceptance tests.

Check PageObjects pattern - You create LoginPage class with proper methods like loginAs(String username, String password), loginAsExpectingError(String username, String password). You write other classes like that - it gives you automation framework for your app. You can use this in the following way:

On integration level you are checking if application components work properly if you provide proper credentials (loginAs) and that when you are provide wrong credentials (loginAsExpectingError).

On acceptance level you use LoginPage.loginAs() to make first step in your acceptance test. Second could be something like MainPage.addSomeFoos(). Then MainPage.addSomeBars(). Then MainPage.logOut().

If your unit tests pass, then run integration tests, if they pass run acceptance tests.