4 thoughts on “BDD Test Naming Experiment”

1. I’m more in a Given – when – then place: http://vanryswyckjan.blogspot.com/2008/02/exploring-bdd-style-specifications-as.html

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

2. I think its a good start. The tests are still very ‘code’ like in nature, focused on the objects themselves (Employee, Repo, EmailAddress).

   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.

3. I agree with Jarod. I’m also a fan of the When-Then approach. The framework from Scott Bellware he is referring to is called SpecUnit.NET and can be found on Google Code. (http://code.google.com/p/specunit-net/). You can take a look at the banking example for getting an idea of the naming style.

4. lately i’ve been encoding the Given/When on the test class name and every test starts with Should (i’m kinda leaning more to Given/When/Should).

   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

Comments are closed.