Is Software Becoming More Testable?

Sky-Tiger

Leverage the use of dependency frameworks

If the architecture permits the use of frameworks, consider using a dependency injection framework like Spring. Spring framework allows externalizing the dependencies by moving them to a configuration file (xml file). The advantages are:

    * A nice clean way of managing dependencies
    * Sparse use of singletons
    * Easy to plug in and out different implementations of the dependencies
    * In built support for unit testing

Define and document the method functionality

The method documentation should clearly state what the method is expected to do. If there are branches within the method, the documentation should explain the conditional logic. Consider giving as much documentation as possible to help the unit test developer to understand the method’s purpose.
Define and document the method contract

Design by contract (DBC) is a way of writing the method documentation so that it clearly defines what the code will do. It should clearly capture the preconditions, post conditions and any invariants should be clearly documented.

The following tags can be used for method documents:
@pre – Conditions that have to be true before method can be called
@post – Conditions that should be true after the method gets executed
@invariant – This is a constraint on the object state that is guaranteed to be true at all times, such as Collection.size() == Collection.toArray().length().

In the detailed design phase when identifying methods and behavior of classes, also identify the contract of the method. This contract specifies terms under which the code will be executed. The contract defines the following and this has to be documented in the method specification.

    * Input – Range of expected values for the input(s) of the method
    * Output - Range of expected values for output(s) of the method
    * Boundary - Clearly state the boundary conditions for the method. The conditions in which the method would fail (negative flows)
    * Exception – The cases when the method would fail by an exception. Document the input values that could cause this. Document the expected behavior of the system when the method fails through an exception.
    * Assumptions – Document the assumptions (if any) on how the method will behave. For example methods that deal with data in some formats should document the format. The assumption is that the data format would not change.

Sky-Tiger

Before writing the unit tests

Before getting started on writing the unit tests, it is very important to read the method documentation and understand the purpose of the method. This would give a complete idea about what is to be tested. It is also necessary to formulate the various conditions that are bad or invalid and the different scenarios in which the method would run into errors. Sometimes when the method document is not sufficient it would be very useful to update the method document with all the details that are needed to unit test. Some pointers to keep in mind before starting the unit test are:

    * Write the unit tests based on the documentation – It is important that the method documentation details the behavior of the method. If a public method does not give out all the necessary details, it might be a good idea to add that documentation as the developer. The idea is to adhere to the verbal contract of the method.
    * Write the unit tests based on the code – Revisit the code to be unit tested. Understand if it is working as the documentation suggests. If there is a difference between the contract and the code, then one of them must be fixed. Once the code looks fine there would be a clear idea of how to unit test. The places where assertions and failures have to be tested could be understood.
    * Write the unit tests based on the expected results – Test for all the scenarios – success, failure, boundary conditions and exceptions.
    * Unit Test the assumptions – there would be assumptions in the code when there are dependencies. For example an API call could be assumed to work always. It is good to unit test the piece if the API did not function as defined. By this we can see if the code is able to recover from an error and not crash.

Sky-Tiger

Advantages of thinking about unit testing upfront

Thinking about unit testing during design, leads to a good design. Unit tests are not just pieces to catch ‘bugs’, they also drive the design. Unit tests enforce the contract of the classes and methods and thus making sure the design adheres to the contract of the system. Some of the advantages of thinking of unit testing during design are following:

    * Unit tests drive the developers to think about interfaces. This practice leads to writing loosely coupled code. It also benefits in writing good apis.
    * Unit tests lead to better design by allowing a right mix of composition and interfaces
    * Unit tests drive the need for good method documentation. Remember the standard: If your program isn’t worth documenting, it probably isn’t worth running (Nagler, 1995)

justforregister

nice job