Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This is an attempt to reorganize and update Testing and it's child pages. It's still under construction.

Tests in OpenMRS are being run with every commit by ci.openmrs.org and travis-ci.org/openmrs.

We aim to start organizing tests in OpenMRS codebase into five categories:

  1. Unit Tests
  2. Component Tests
  3. Integration Tests
  4. Performance Tests
  5. Manual Tests

If you look at our codebase, you will see many tests do not follow guidelines outlined below. In fact the guidelines are yet to be further adjusted and discussed.

The goal is not to clean up old tests rather write new tests following the best practices.

Unit Tests

JUnit is the test framework we use in OpenMRS core and modules. In addition we use Mockito to create mocks (simulated objects). Here are a few guidelines you should stick to when writing unit tests:

  1. Each class should have a corresponding class with unit tests e.g. Concept should have a corresponding ConceptTest class.
  2. If you have a class implementing an interface, then create a test class for the actual implementation.
  3. Classes with unit tests may extend BaseContextMockTest, if they need to mock legacy code calling services with Context.get...Service().
  4. Classes with unit tests must not extend BaseContextSensitiveTest and its subclasses BaseWebContextSensitiveTestBaseModuleContextSensitiveTest, BaseModuleWebContextSensitiveTest.
  5. The test method should start from the tested method name (unit of work) followed by "_should" and the expected behavior e.g. toString_shouldIncludeNameAndDescriptionFields_ifNotBlank. "_if" should be included if the expected behavior depends on some state/condition.
  6. It is considered a good practice to follow //given //when //then pattern in tests:
    (EXAMPLE HERE)
  7. Always assert with assertThat using static import for org.junit.Assert.* (explained here). The use of assertFalse, assertTrue, assertEquals is deprecated and not allowed in new tests.

  8. Prefer implementing FeatureMatcher if you cannot find any suitable matcher in Matchers.*.
  9. Prefer using @Mock annotated test class fields for creating mocks and @InjectMocks for injecting them into tested objects. See BaseContextMockTest.

More to come...

 

  • No labels