Unit testing is essentially that first rung of the testing process, where individual units or components are tested to ensure they perform as designed. By running unit tests on your software, you give yourself a good foundation that will help when it comes to the remaining testing activities. However, unit tests of a poor quality will significantly reduce the benefit gained from running them, and can potentially introduce issues that could have been easily avoided.

As with most things relating to software, an efficient way to ensure quality in your tests is to follow best practice guidelines. So should you find yourself seeking quality, have a look at these testing guidelines, and you should find that by making a few simple changes to how you work you should begin to see an improvement.

Make Each Test Independent

If there is one thing you should remember when it comes to developing software, it should be that there is a very high chance of the customer, or end user, changing the requirements. In fact, very few development projects make it through to completion with the exact same requirements they started with. With this in mind, it’s fair to say that tests should allow for unexpected changes of features and functions.

When it comes to unit testing, caution should be given that the units under test could be altered or removed at any point of the development. Which is why test cases should be written in such a manner that they do not rely on any other test. By working in this way, you can avoid unnecessary time and expenses being wasted on repairing broken tests.

Independent Unit Tests

Don’t Make Unnecessary Assertions

Working at a computer

Even small, simple software systems can be comprised of a surprisingly high number of units, each of which will need to be tested in order to prove functionality. Ideally, when you write your test cases, you should take care to ensure that each test will only be checking the focus point of that test. Therefore, when you write your test cases you should take care to limit the number of assertions for each test case to the bare minimum, i.e. one or two per test case.

If you find yourself continually adding more assertions, it would be beneficial to introduce additional test cases. Although working in this way will result in more time and effort being spent in the short term, by limiting your assertions you simplify the process of identifying the sources of the error should a test fail. Additionally reducing the number of assertions reduces the risk of having to rework tests further down the line should any units be removed or altered.

Only Test One Code Unit At A Time

One of the many benefits of running unit tests on your code is that, by looking at each unit individually, you can isolate and address problematic areas of code. As you can imagine to make the most of this benefit you need to make sure to only test one unit at a time.

Additionally by tying two units together into a single test, whilst you may not experience problems in the short term, you may run into trouble further down the line. For example if you were to utilise one of your units as part of another system, due to reliance on the other unit involved, you would find yourself unable to transfer the test to the new system. On the flip side if you were to change or remove one of the units you would only end up breaking the test for both units.

One Unit At A Time

Don’t Unit-Test Configuration Settings

In order to get the most out of unit testing you do need to put in a certain amount of time and effort. So why increase this effort by unit testing your configuration data? The purpose of unit testing is to see if your code works, not see if the configuration data is correct this falls to other tests such as System or Acceptance testing.

Name Your Unit Tests Clearly And Consistently

Clearly Name Your Unit Tests

Following consistent naming conventions is a good practice to follow across all aspects of software development. By being consistent with your names, should anyone else need to read through your code and understand which function is being addressed.

In terms of Unit testing utilising a clear naming convention such as, Method-Name Under Test_Scenario_Expected-Outcome, helps to avoid excessive comments as well as improve maintainability. Not to mention the added benefit that in situations where a test fails, it simplifies the process of identifying which function is experiencing bugs.

Use Parameterized Tests

The problem with testing any piece of software is that it doesn’t take long for the level of complexity to increase exponentially. More often than not functions will be expected to handle a large number of values in various combinations. Trying to write test cases to cover every single value and combination a function could possibly encounter would be both foolish and a waste of time.

On the other hand, making use of parameterized tests to drive test cases where the unit under test will be handling a large variety of values, can help to ‘throw’ values at a specific function. Whilst there is undoubtedly a benefit in utilising such tests as part of your testing process, it is important to remember that in most cases it is simply not practical to test every single potential parameter combination.

Testing All The Possibilities

Contact Zircon

Address: Telephone: Key Contacts:
Bellefield House
Hilperton Road
BA14 7FP
Tel: 01225 76 44 44
Fax: 01225 75 30 87
Sales & Marketing Director: Phil Cooper
Business Development Manager: Arron Dando