Developer Testing

Owned by Former user (Deleted)
Last updated: Sept 07, 2010Version comment
2 min read

Developer Testing on MifosContents::

Overview

Theres an ongoing development effort around EvolvingTheMifosCodeBase. Roughly speaking this involves moving towards a CLEAN LAYERED ARCHITECTURE and the creation of rich domain-oriented APIs that will make the code base easier to understand and use. The google summer of code projects for 2010 SoC2010Ideas are closely aligned with these goals.

In HowToRefactorStrutsActionClassesToServiceFacadePattern, we document the first steps of moving to a CLEAN LAYERED ARCHITECTURE. One of the key benifits of tests is that they should give us the confidence to refactor however there are currently a number of problems with the existing test suite.

Types of tests

At present we have the following developer tests:

Integrated Tests

  1. edge-to-edge: functional tests driven through ui that test edge-to-edge (These tests exist in the acceptanceTest module)
  2. sub-system: tests that verify a group of components working together i.e. DAO + ORM + Database (These tests end with name IntegrationTest.java)

Unit Tests

  1. unit tests: tests that test a unit in isolation from its dependencies/collaborators (These tests end with name Test.java)

Existing Problems

In general, the existing test suite fails to achieve most of the goals of test automation, the result of which is that we have the worse of both worlds; we have incurred the cost of writing and maintaining tests but this has not resulted in a higher quality product(both internal and external) or reduced the effort required to test the application to a level that gives us confidence.

Problem: Tests are highly coupled to production

Below are some examples of how production and test code get coupled together:

  1. Directly calling API to setup state which is not part of the 'behaviour' being tested. In general this makes it harder to refactor the given API and causes the tests to become an 'anchor' to change. The tests should use a test specific creational pattern which in turn can call the API.

The test suite we want

We want to write a test suite that seeks to achieve the goals of test automation guided by a set of principles .

Principles

  1. Don't couple tests to production