Stéphane Leblanc Version 0 (2012-04-30)

Unit Testing

Providing an introduction to TDD is outside of the scope of this guide. However, TDD has a tremendous potential for helping future developers to maintain and extend AoUrnToRam. However, if you are not familiar with TDD, the learning curve should not be underestimated. This is true even if you are an experimented developer. Unit testing has its own challenges and can turn into a double-edged sword faster than one may think.

After the first three months of development, AoUrnToRam had 100 unit tests. At this point, the unit tests became a real maintenance burden. During the development of iwToStepView, we even stopped writing tests completely. This is the reason why no unit tests exist for iwToStepView. However, the problematic tests have been refactored since then and the number of unit tests has now reached 238 without creating any maintenance problems or slowing down the development.

These tests are not perfect. Still, they provide 238 examples for developers who may not be familiar with TDD and willing to try this methodology. You will notice that the methods provided through the TestHelpers (TestFactory and CustomAsserts) make it much easier to write unit tests. Still, if you are not familiar with writing unit tests, the Part 1 of XUnit test patterns¹ would be a great place to start. If you are curious to know more about the TDD methodology, Test Driven Development: By Example² by Kent Beck is a good book.

The naming of the test is a crucial matter for unit testing. Test names can be thought of as micro-requirements written by and for developers. Indeed, good names allow developers to understand the purpose of a test without reading the test code. In order to provide the benefit describe above, test names must respect the following convention. Note that SUT stands for System Under Test.

Test Class

1. 
   SUT transformation name
   
2. 
   "_"+SUT class name
   
3. 
   "_"+SUT fixture (optional)
   
4. 
   "TestCase"
   

Test Method

1. 
   "test"
   
2. 
   SUT method name
   
3. 
   "_"+SUT input/preState important characteristics (optional)
   
4. 
   "_should"+expected behaviour
   

Moreover, the traceability between a test and the features can be ensured by using the @feature attribute. Unit tests are very specific; thus, they are seldom related to more than one feature. When in doubt, use the feature for which the test was created first.

Example:

@feature "FeaNamingOfRAMStep"

operation testDeepFirstSearch_Unexplored_ShouldLinkCurrentStep() is do ...

Instead of manually adding the @feature to each new test, one can use any text editor (e.g. Sublime Text Editor) and the following regular expressions in order to add the @feature attribute to all the tests that are not linked with a feature.

When these conventions are respected, the test names convey the essential information concerning the test. It is even possible to parse the test cases source file to get the essential information concerning all unit tests. This information can be used as micro-requirements by the developers. Table provides an example for the feature FeaWorkflowInstantiationWithoutStubs which is solely related to the transformation IwToJavaInstantiator. The list of all features, their description, and the list of all test cases broken down by features can be found on the project wiki.