OpenMRS uses Unit testing. Why is it important and why should we learn it?




Before talking about unit testing and why it is preferred by large and open-source organizations like OpenMRS, let me introduce "code testing" to those without a background in code development. 
Much like field testing a vehicle before launching it to the consumers, or testing a vaccine before releasing it to the public, a code needs to be tested thoroughly before it is deployed and shared with clients. How thorough? As thorough as it can be. It is very important to test every possible case and every code block. All accepted input types should be tested and their outputs respectively. It is crucial for the longevity of the code and the developer producing it, to test their code before releasing it. It prevents any future recalls and resource allocation for fixing something that should have been caught in a testing phase. 




In the old days of programming, manual testing was one of the only options available. Even though it is still used by many, it is not wise to manually test your code especially if the code is part of a larger organization or code structure. Manual testing is tiresome, inefficient, and not thorough. Many automated testing methods are in use today and unit testing is one of them. In my research of my foss project, I noticed that OpenMRS heavily relies on unit testing and is the core component of their testing methods. 

In order to deploy unit testing, you need to first have a set code structure that allows unit testing to be efficient. Small modules of codes are the best practice for an efficient unit testing follow up. These small modules perform one specific task each for unit tests. A unit test tests a small module by encapsulation and does not require the module to connect to any external resources like a database or other module integration. Any external dependencies, meaning any module or component that relies on another component to work, need to go through a "mock" process. They need to be faked in order to unit test a module. A fake implementation of the dependency is used to allow the component to be tested, run properly, and in turn, tested properly. 

A quick example of separate components that could be unit tested in a code is:

public class CarInventory {
    public Car Tesla(string model) {
        var car = new Car
        {
            Make = "Tesla";
            Model =  model;
        };
        return car;
    }

public Car Ford(string model) {
        var car = new Car
        {
            Make = "Ford";
            Model =  model;
        };
        return car;
    }

}

In this example, Tesla() and Ford() are two separate modules. They can individually be tested by unit tests. This allows simple readability and execution of tests. 



Comments

Popular posts from this blog

Make way for GPLV3

When a code rot can be the difference between life and death.

Privacy and Personal Data