However, when testing small systems where there is only one specification per context, the testcase-class-per-fixture syntax becomes overwhelming and cumbersome to user.
For this reason I’m sometimes using a more compact format for the specifications:
1: public void $Method$_Given$Context$_Should$ExpectedBehaviour$()
| $MethodName$ | The system under test (SUT), will often be a method name |
| $Context$ | The situation/scenario |
| $ExpectedBehaviour$ | The expected outcome of the given context |
Example specifications:
1: namespace BDDSimpleStyleExample
2: {
3: [TestClass]
4: public class DateTimeSpecifications
5: {
6: [TestMethod]
7: public void AddDays_GivenTodayIs1stOfJanuaryAndAddingTwoDays_ShouldReturnJanuary3rd()
8: {
9: //Arrange (setup up context / fixture, usually multiple lines of code)
10: var today = new DateTime(2009, 1, 1);
11:
12: //Act (one line of code, invoke the System Under Test)
13: DateTime result = today.AddDays(2);
14:
15: //Assert (Usually ONE assert / specification)
16: Assert.AreEqual(new DateTime(2009, 1, 3), result);
17: }
18:
19: [TestMethod]
20: public void AddDays_GivenDateIsLastDayOfMonthAndAddingOneDay_ShouldReturnFirstDayOfNextMonths()
21: {
22: //Arrange
23: var today = new DateTime(2009, 1, 31);
24:
25: //Act
26: DateTime result = today.AddDays(1);
27:
28: //Assert
29: Assert.AreEqual(new DateTime(2009, 2, 1), result);
30: }
31: }
32: }
The disadvantages of using this style is that the method names in the test class may get very long, and the test results output isn’t formatted as good as it would have been when using one test case class per fixture:
The following ReSharper live template can be used to quickly add new specifications/tests:
1: [TestMethod]
2: public void $Method$_Given$Context$_Should$ExpectedBehaviour$()
3: {
4: //Arrange
5: $body$
6:
7: //Act
8:
9: //Assert
11: }