Unit Testing is the idea of writing additional code, called test code, for the purpose of testing the smallest blocks of production code to the full extent possible to make sure those blocks of code are error free.

Code is usually designed into Classes or Objects. The term “Class” and the term “Object” are usually used interchangeably. Classes are made up of variables and functions that include Constructors, Methods, and Properties but they may also include sub-classes.

For each Object in code, you should have a Unit Test for that object. For each method in an Object, the correlating Unit Test should have a test. In fact, a test should exist that makes sure that every line of your code functions as expected.

Code Coverage

Unit Tests are about making sure each line of code functions properly. A Unit Test will execute lines of codes. Imagine you have 100 lines of code and a Unit Test tests only 50 lines of code. You only have 50% code coverage. The other 50% of you code is untested.

Cyclomatic Complexity

Cyclomatic Complexity is a measurement of how complex your code is. This usually comes up in Unit Testing because in order to get 100% code coverage, one has to tests every possible path of code. The more your code branches, the more complex the code is.

If you have to write twenty tests just to get 100% coverage for a single function, you can bet your cyclomatic complexity is too high and you should probably break the function up or reconsider the design.

Parameter Value Coverage

Parameter Value Coverage is the idea of checking both expected and unexpected values for a given type. Often bugs occur because testing is not done on an a type that occurs unexpectedly at run time. Often a value is unexpectedly null and null was not handled, causing the infamous null reference exception.

How can we find these bugs before a customer reports them? A unit test can catch these bugs. We can make lists of anything we can think of that might react differently.

For example, imagine a function that takes a string. What should we try to test:

An actual string: “SomeText”;

An uninitialized string: null;

A blank string: “”

A string with only whitespace: ” “;

Now imaging a function takes an object called PersonName that has a string member for FirstName and LastName value. We should try to test some of the above.

A PersonObject but nothing populated: new PersonName();

A PersonObject but everything populated: new PersonName() {FirstName=”John”, LastName=”Johnson”};

A PersonObject but partially populated: new PersonName() {LastName=”Johnson”} || new PersonName() {FirstName=”John”};

An uninitialized PersonName object: null;

Here is a test that will check for null in the compare strings code.

Note: There is a decision to make here. If comparing two string objects and both are null, do you want to return true, because both are null so they match? Or do you want to return false, because neither are even strings? For the code below, I’ll assume two null strings should not be considered equal.

Now your unit test is going to encounter a System.NullReferenceExecption. Assuming you write Unit Tests before you release your code to a customer, you will catch the bug long before the code reaches a customer and fix it.

What is the code coverage of this Unit Test? (What percent of the Code is Unit Tested?)

You have an enum with twenty items in it. One function has a switch on the enum with all twenty possibilities. The cyclomatic complexity appears to be high and is causing a red flag? Should you change your code? Why or Why not?

Assume you finish the unit test so that the code is 100% covered. What reasons exist for needing still more tests on that code?

My other blogs

Entries (RSS) and Comments (RSS). Copyright ® Rhyous.com Linking to content on this site is allowed without permission and as many as ten lines of any article can be used along with such link. Any other use of the content is allowed only by permission of Rhyous.com.