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.