How to write unit tests for utility programs

Question

I am working on a C# console application that loads the data from a third party and bulk inserts into tables. Basically the code consists of a static method with logging statements. In these scenarios, how does one write the unit test cases?

Example code

void Main(string[] args)
{
    // for loop here to read config from XML file

    // initialize third party library
    ReportLib objLib = new ReportLib();


    DataTable dt = objLib.Refresh("test");

    //call SQL bulk copy
    DBHelper.BulkCopy(dt, dictmappings, destTblName);//dbhelper is static class

}

Answer 1

Actually, given your case is really that small and simple as it looks like in your example code, I would probably omit any unit test and write an automated integration or system test instead.

Here is my outline of such a test:

• provide a fixed XML config file as part of your test suite
• clear the destination table in your test database
• run your program (either as a separate process, or by moving the contents of your Main function into a separate function in a separate DLL you can easily reference and call from your test DLL)
• check if the destination table now has the expected contents

You can use a tool like NUnit for such a kind of test, too, like for "real" unit tests (that's why people sometimes call these kind of tests incorrectly unit tests, too).

Answer 2

use a mock data source, mock data interface, and mock log. If your code just reads in data and calls someone else's methods, that's what your unit test.

Feel free to use your unit test framework to test the whole process if possible, but that may be more of an integration test.

Answer 3

Move all of your code that actually does the work into a stand alone library. Break it out into small chunks and write a test for each chunk. If you can look at a block of code and say "this code does (insert action) and..." then it needs to be two or more separate methods or classes. Write your data access layer in such a way that you can write mock classes to pass in fake data to your logic when testing.

If you structure your application in logic layers, then you can easily fake out the parts you don't care about when testing a single piece of code.

Answer 4

Also, remember that a unit test is a unit test. Not an integration test. Don't fall into a familiar pit an try to test the entire workings of your commandline tool.

Test fragments of your utility. If that seems impossible because you only have a small class, decide to skip unittesting because the utility is trivial, or split up your program into seperate modulesthat are testable.

Answer 5

Most of the times, my utilities are simple 20-lines scripts that I use daily/weekly/monthly, and do one thing. If you execute the utility, it'll be immediately obvious that the script is not working.

You don't need unit tests for such utilities.

Answer 6

Add a couple lines at the end of the script that verify the data made it into the tables. If they did not, then throw an exception or log the error. KISS is definitely the way to go with this sort of thing. If this script becomes part of a larger system, you can always refactor out this simple catch code into an integration test.