Given_AcmeEmployee_When_Create.Should_setup_Id
Given_AcmeEmployee_When_Create.Should_setup_Name
Given_AcmeEmployee_When_Create.Should_setup_LastName

Given_AcmeEmployeeRepository_When_Delete_Employee.Should_not_have_Employee
Given_AcmeEmployeeRepository_When_ClearAll_Employees.Should_not_have_any_Employee

also notice that VS support for test lists is awful. i’d rather have a test list named ‘Given_Context’, then the test name ‘When_Action’ and every test name ‘Should_do something’. in that setup i would use 3 columns in the test result window. However, like i said, VS support for test list is pathetic

cheers
mike

The idea with BDD – Specification Context is that we want to take it to the ‘Behavior’ level. Following a good naming convention will force you to drive the behavior out. This is where is gets confusing as the ideas are fairly new. There are a lot of camps here as far as naming and structuring tests goes. The Given\When\Then, Because\It, When\Should.

I prefer the When\Should approach. The ‘When’ here represents the class name. The class will be responsible for setting up the ‘Context’ of the behavior (Think SetUp). The ‘Should’ represents the test methods of the class, the ‘Specification’.

So taking your first class here AcmeEmployee_Should, we could change that represent some sort of event that occurs. I am thinking:

When_An_Employee_Is_Created: (Context – create an employee)
-Should_Have_A_Unique_Identity (Assert Specification)
-Should_Have_A_First_Name (Assert Specification)
-Email_Address_Should_Be_Valid (Assert Specification)
Etc.

So we have taken test focus away from the AcmeEmployee, and applied it to the behavior of when an employee is created. (And of course moved the code into a factory)

Lets stab at one more, moving the focus away from the repository, to something that it “does”.

When_Adding_A_New_Employee
- Employee_Should_Not_Exist
- Audit_Should_Indicate_Added_Date
- Should_Record_Name_Of_User_Adding_Employee

When_Attempting_To_Add_An_Existing_Employee
- Should_Notify_User_Exists
etc, etc

Notice we do not talk about exceptions, id’s, singletons, construction etc. Just plain ol english a user might understand. We end up with a lot more test classes, but they are much more meaningful and easier comprehend. For a given context we may have 5 specifications or so, plus or minus 3. Ideally, we want all the work to happen in the setup (CreateContext, Before_Each_Specification) with the specification being one line of english as the test name, and one line of code doing the assertion.

Most of this view comes from Scott Bellware’s style of BDD.(caught his session at Alt.Net Seattle) I think he has an app/runner that he is working on, though I just use NUnit.

http://specunit-net.googlecode.com/files/SpecUnit.Specs.html