Information
What
The OpenMRS Test-a-Thon is a code-a-thon event that allow developers to work together to increase and improve our testing process. The ultimate goal is to make the OpenMRS platform a more stable and robust piece of software. However, we're also hoping to help novice developers get a better understanding of test driven development.
When
- Start: Noon EDT on May 16 - Sabado Gigante!
- Stop: Noon EDT on May 17 - Sunday, Sunday, Sunday
Where
The test-a-thon will take place entirely online. You can join us on the OpenMRS IRC Channel anytime Saturday afternoon (EDT).
Minutes
Test-a-thon Minutes: The minutes of the testathon will be maintained in this google document.
- Anyone can view this document.
- If you want write access, please email
email|justin|openmrs.org
for permission.
Important Notes
If you see a*bug that needs to be fixed, write an @should behavior to describe the expected behavior and a JUnit test that fails!
If you see something that looks questionable, note it in the*Questions section of the Test-a-thon Minutes Google Document.
If that*something questionable you see is refactoring, make a note of it, but don't refactor today ... we're just about testing today.
Attendees
- Ben Wolfe
- Justin Miranda
- Glen McCallum (Saturday only)
- Win Ribeka
- You!
Required Reading
"Every programmer knows they should write tests for their code. Few do. The universal response to "Why not?" is "I'm in too much of a hurry." This quickly becomes a vicious cycle- the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel. " --Socrates
Resources
- Intro to Behavioral Driven Testing
- JUnit Best Practices
- JUnit Anti Patterns
- OpenMRS Testing
- OpenMRS HOWTO Get started with unit tests
- OpenMRS HOWTO Write unit tests with @should
- OpenMRS Unit Test Roadmap
- OpenMRS Unit Test Conventions
- Improve documentation about how to do tests Unit Testing
- Developer conventions about testing Unit Testing Conventions
- Develop a unit testing roadmap (See Unit Testing Roadmap)
Goals
Increase the number of test cases to*1000 by the end of the weekend.
- We currently have*696 unit tests in trunk.
- Improve code base by making code comply with their expected behaviors.
- Improve existing test cases
- Make writing units tests easier
- Make writing web unit testing easier
- Increase test coverage of OpenMRS API and web
- Learn behavior driven development (BDD)
- Learn best practices for behavior driven development
- Learn JUnit, dbunit, and other frameworks
Getting Started
Rough outline of how to get started as a developer.
Develpers
Now
Checkout thetestathon* branch.
- Search codebase for '@should' to see examples of methods with expected behaviors.
View thecontinuous integration server* that set up for the testathon branch.
- View the '''available test cases
- Find a test class that does not seem to have very good test coverage
- *org.openmrs.Encounter is an example of a class with good test coverage :
- *org.openmrs.Obs is an example of a class with poor test coverage:
Open the associated class (i.e.org.openmrs.Obs*) in Eclipse.
- Add an @should annotation to describe each intended behavior of the method.
/**
- @return Returns true if this Obs is complex.
- @should return true if the concept is complex
*/
public boolean isComplex() {
if (getConcept() != null) {
return getConcept().isComplex();
}
return false;
}
Later
Open the associated test class (i.e.org.openmrs.ObsTest*) in Eclipse
- Create a test method in this JUnit test following the conventions below
- Add @Test annotation
- Add @Verifies (value = "(replace with @should behavior description)", method = "(replace with methodName)")
- The test method name should following this convention: methodName + '_should' + behaviorDescriptionUsingCamelCase
/**
- @see {@link Obs#isComplex()}
*/
@Test
@Verifies(value = "should return true if the concept is complex", method = "isComplex()")
public void isComplex_shouldReturnTrueIfTheConceptIsComplex() throws Exception {
ConceptDatatype cd = new ConceptDatatype();
cd.setName("Complex");
cd.setHl7Abbreviation("ED");
ConceptComplex complexConcept = new ConceptComplex();
complexConcept.setDatatype(cd);
Obs obs = new Obs();
obs.setConcept(complexConcept);
Assert.assertTrue(obs.isComplex());
}
- Run test within Eclipse
- Right-click the test class and select*Run As > JUnit Test.
- Commit code to subversion with commit message
testathon:
- Added test case: ObsTest.isComplex() should return true if the concept is complex.
- The continuous integration server will periodically build the branch and run all of the tests. If your test fails, you will be notified via email.
- Don't be afraid to write test cases that break the existing code base. We want to also find bugs or methods that don't behave as expected.
Documenters
- Checkout the 'testathon' branch from:
Moderators
- Write @should's for new test cases
- Run test generator over testathon to create new blank tests.
- Clean up existing test cases.
Next Steps
(formerly "things that must be complete before we start")
Developers
- Read the required reading above.
- Join the OpenMRS IRC Channel (using your favorite IRC client).
- Jump on the Test-a-thon Minutes document to
Organizers
- Add @should behaviors to javadoc of methods we want to cover.
- Run the OpenMRS Test Generator over the testathon branch.
- Commit @should behaviors periodically.
- Need to come up with a goal! 500 new unit tests or 90% test coverage?