Technical Workshop 05 16-05 17 2009 Agenda

Owned by
Former user (Deleted)
Last updated: Aug 18, 2010
3 min read

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

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

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

  1. Checkout the 'testathon' branch from:

Moderators

  1. Write @should's for new test cases
  2. Run test generator over testathon to create new blank tests.
  3. Clean up existing test cases.

Next Steps

(formerly "things that must be complete before we start")

Developers

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?