Unit Testing Conventions

This page is marked to be re-organized.
We are in the process of evolving our unit testing conventions

Introduction

Our unit tests are written in JUnit. We follow a premise that is a half-step towards Behavior Driven Development:

Unit tests should be very short and test only one small part (behavior) of a method
The unit test name should be descriptive enough to describe the entire test

At least one unit test method per nontrivial public method (99% of methods will need multiple tests)
One unit test class per new class
Every unit test must use Assert.assert___ methods to test output...not println statements!
If committing new code, the unit tests for that code should be committed at the same time
If fixing a bug, write a failing test proving the bug, then fix the code to make the test pass.
Every unit test method should be well documented (javadoc) about what it is expected and where it is operating on.
Every database-based test must be accompanied by a in-memory dbunit test dataset

Plain old java object testing:
The getters and setters do not have to be tested unless they are doing something more than getting/setting an internal variable
See [EncounterTest.java http://dev.openmrs.org/browser/openmrs/trunk/test/api/org/openmrs/test/EncounterTest.java], [EncounterType.java http://dev.openmrs.org/browser/openmrs/trunk/test/api/org/openmrs/test/EncounterTypeTest.java]

Service layer testing:
All methods in the ___Service classes should be testing with proper input, improper input, and improper data in between.
See [EncounterServiceTest.java http://dev.openmrs.org/browser/openmrs/trunk/test/api/org/openmrs/test/api/EncounterServiceTest.java]

Database layer testing:
Most database methods are testing in the process of testing the aforementioned Service Layer Testing. However, some database layer methods are not exposed through Service layer methods. These methods need to be tested.
See [EncounterDAOTest.java http://dev.openmrs.org/browser/openmrs/trunk/test/api/org/openmrs/test/api/db/EncounterDAOTest.java]

Editor testing:
All set and get methods in the editor require testing. See [DrugEditorTest.java http://dev.openmrs.org/browser/openmrs/trunk/test/api/org/openmrs/test/propertyeditor/DrugEditorTest.java]
See [DrugEditor.java http://dev.openmrs.org/browser/openmrs/trunk/src/api/org/openmrs/propertyeditor/DrugEditor.java]

What type of incentives can we provide to a developer to make it rewarding to write test cases?
How can we involve implementers into helping to provide test cases for code they want?
- Can we add a process to the request workflow that requires/encourages [written] test cases (or user stories)?