How do I break down a "full stack" feature into acceptance, integration, and unit tests?

I am new to Behavior Driven Development and I am trying to learn it. I am using MSpec & Watin for acceptance tests and MSpec for Unit tests with ASP.Net MVC 4. I have a simple scenario of user registration.

When a user enters username, password, email, etc. and clicks on register button
It should validate email address
It should check that the username already does not exist
It should register the user
It should send a welcome email
It should redirect to the home page

There are things that I want to test that can’t be tested using Watin like sending email, check if the user exists or not etc. These will be part of the controller tests. Does this means that my acceptance test will only be that when a user registers he should be redirected to the home page? How do I break this entire process into tests?

If these checks are implemented in various tests and different level then how do I get a summary report that is available with MSpec that I have implemented all the features? I am a bit confused as to how people break these tasks and then how they get the collective report etc.

Solution

Your unit tests would consist of something like:

Test that the code which registers a user throws an exception if the user name was not given.
Test whether the code that validates a password works.

Basically taking small units of the code and testing them.

For the acceptance tests, your taking that to the next level and integrating these features to ensure they work. So you could have an acceptance test that checks the whole registration feature:

Given I am a new user
When I complete the register user form
Then I will be redirected to the home page

Given I am a new user
When I complete the register user form
And I have not entered a valid password
Then I will be shown an error message

Or something in that region.

Personally I'm not a huge fan of writing tests that test the user interface, since the UI can change frequently (meaning you have to fix the tests broken by those changes); plus I felt like I was duplicating effort by writing unit tests followed by acceptance tests.

However, ATDD can benefit you when it comes to your customer, since you can communicate to them how you have been testing the application. It's much easier to show them a BDD test (which is written text) rather then public void ValidatePassword_PasswordNotValid_ExpectFalse.

This is one of those scenarios where you need to try ATDD out to know whether you will benefit from it.