Fun Facts on Unit Testing: Great tips for writing Great Unit tests

In recent times, Unit testing has been one of the Software development cycle that devs consider as important. This is not far from the truth, unit testing is simply an exercise taken to check reactions of every unit in our codes(application as the case may be). This thread will careful go through the concept and motive behind unit testing, and the workability as a whole.

Generally, a unit is a single procedure, method or other independent functions with behavioural tendencies i.e a procedure with functionality/ies. it is safe to say in generic tone that unit is the smallest testable portion of any application. In the same vein, it is one of the ways developers check the correctness of the code they have written be it in a usual or unusual situations. Having said this, it is important to state the motive behind unit testing. As against some developers’ view, unit test is not an effective way to discover or find bugs/regressions.

In its self-sufficient meaning, Unit test is an exercise which allows the examination of each unit of our codes separately. In essence, when you run your application, all those units that you have written test for have to plug together to work and these coming up as a whole becomes more complex and subtle than the whole separated parts that have gone through tests. That A and B works independent of each  other doesn’t prove that they can compatibly be configured together to work as a whole.

The essence of saying the above is simply to refute the notion that unit tests are effective way of finding bugs. So, whence finding bugs on your application, it’s better and effective to run the application as a whole as it will run in production. Doing this type of testing to determine breakages, that can come in term as an intergration testing which typically requires numerous techniques and technologies than that of unit testing.

A good programmer once said “Essentially, Unit testing should be seen as part of design process, as it is in TDD(TEST DRIVEN DEVELOPMENT)”. The above simply translate to the fact that Unit testing should be employed as a support system to the design steps in a way that allows the developer to identify each smallest part in the system alongside its behaviour when placed under different conditions, taking into cognizance independent testing of these units.

So, dear developers, readers, engineers, steadily fasten your seat belt as I take you through some of the popular tips for writing awesome unit tests.

The first consideration is simple, always test one code unit at a time! When testing a unit of our code,a unit can have multiple use cases and while testing these use cases, it is always good to have a seperate test case for each of the case available.  Let’s back this up with a practical backup. In intances when you have to test a method that takes 2 parameters and returns 1 value. Some of the use cases that could be considered are: Making the first parameter null which should throw Invalid paraeter exception; second parameter coming as null also throwing invalid parameter exception; the two parameters being null and lastly; testing the validity of the value returned.

With this, testing becomes easy. While changing or refactoring our codes, more test cases can then be developed to see every reactions given to the new changes. Another consideration is to always avoid unneeded assertions. Let’s take our mind back to this fact, unit tests are specifications to test how a certain behaviour should work, not long list of certain observations of all the things the code do. In essence, unit tests are expected reactions of what ought to be done and not all what it is doing. With this mindset, it is not adviseble to Assert everthing the code is doing, it is better to focus on what you are testing. Upon lose of focus, you might end up faling mutliple testcases for a single reason which doesnt help your application in any way.

To simply explain this, it is good to work with the requirements of your application rather than asserting for all the possible behaviours of your unit. Although some developers are of the opinion that state thus–“The more the test, the less the failure”. Painting practical example of this, if there is a method that functions as Acceptance of credentials for a user and there is a requirement that doesnt allow users below age 18 in a college application, it is good to focus and assert on the requirements for the unit testing for the AgeRequirement than going outside the context of the requirement e.g checking for month of birth etc.

Another consideration is the naming convention. it is good practise to always name your unit tests clearly, unambigiously and consistently. This simply term to you naming your testcases on what they actually do to be descriptive and easy to work around. For instance, a testcase that test for Creation of a model in a car application should always follow the basic logic of the app which will still be effective upon any modification(TestCreateCar_DuplicateId_ShouldThrowException, etc.). In essence, the application logic dictates your testcases naming convention.

Another thing to consider while testing is the configuration settings. Do not unit test configuration settings. In essence, configuration settings are not part of any unit of your code and that is the explanation behind the extraction of the setting in some properties files outiside our whole module. Even at instances when you can write a unit test for the inspection of configuration, it is necessary to only write one or two test cases for checking that configuration loading code is working fine and that’s it! Some developers are of the opinion that the practise of testing all your configuration settings in each different testcases only shows that you are good with “Copy and Paste”.

Needed to conisder, it is better to make each test independent to all the others. Having a chain of unit test cases will cluster the units up and this, is considerably always a blocker to get to the root cause whenever the test cases fails. In essence, testcases being dependent on eachother can cause a tight-coupling kind of situation and upon any change in a test cse, it affects other testcases which the modification may come as an unecessary step.

Another consideration  is that, it is bad to print anything out in unit tests. If properly written with guidelines, tests doesnt need to have any print statement in the test cases. If there is any urge to write any print whatsoever, then revisit the test case/ test cases that you have written then there is/are things wrong. To increase reliability of our application and test steup, it is better to integrate our test cases with build script to make it execute in the production environment automatically.

Lastly, creation of unit tests to target exception is also a good practise while writing tests.  In intsances where your test cases expect exceptions to be thrown in your application, it is good to use the “expected” as a descriptive attribute. In essence, the practise of catching an exception in the catch block and fail or assert method in concluding the test is not adviseable.

Conclusively, unit testing is assertively one of the best software development cycle increasing the quality of our codes/ application as the case may be. It is a general notion to believe that, working with any test cases is better than working with none. All in all, unit testing is a vital aspect of software development cycle that needs absolute attention of all developers.