...

• Each unit test name should be a sentence
• Each unit test should only test one thing
• That one thing the unit test focuses on should be a behavior of the test, not the whole test

The Problem

1. Test - driven development is hard.
   • The developer routinely does not have the time/desire/gumption to create tests before/during development. However, the developer is usually the best one to know what a method is meant
2. We have a large number of existing methods that do not have tests
   • Only the more experienced OpenMRS developers know what each method does and the tests needed
3. We potentially have a large number of developers that have a small amount of time to be able to donate
   • Tests are in one class, methods in the other, which ones are done? which methods need more?

Our Solution

Introducing the "<strong>Should</strong>@should" JavaDoc javadoc annotation. Each API api method will get one or more @should annotations that simply state a behavior of that method that needs testing:

• <strong>Should</strong> not @should not fail given null parameter
• <strong>Should</strong> return @should return empty list if no results
• <strong>Should</strong> execute @should execute in less than thirty seconds
• <strong>Should</strong> find @should find patient given partial name
• <strong>Should</strong> allow@should allow, not allow, fail, return something to, on, with, when, for doing something else

...

Typing out the format for each @should annotation and each JUnit junit test is tedious. We created an Eclipse eclipse plugin that will create the unit test and annotation to match a given @should annotation.

...

package org.openmrs.somepackage;

public class SomeObject {

  **
  * (Descriptive text)
  *
  * @param x (descriptive text)
  * @return (descriptive text)
  *  
  * *<strong>Should</strong>@should get name as written by user with spaces*
  */
  public y methodName(x) {
    // do stuff
  }
}

...