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


6 Answers 6


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).


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.

  • I've updated with code, can you please suggest how to start with. I am sorry I am new to unit test and also, let me know if I need to provide additional info.
    – Sunny
    Jul 11, 2013 at 1:54

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.

  • Thanks for the reply. Could you please provide examples based on my code.
    – Sunny
    Jul 11, 2013 at 2:02
  • 1
    If your code is that short, there really isn't much to test. You don't have any complex logic that you need to verify is being correctly executed. Jul 11, 2013 at 2:22

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.

  • Just because an automated test is not a unit test it does not mean it will not be useful.
    – Doc Brown
    Jul 11, 2013 at 13:35
  • O I never said it wouldn't be useful. But don't write a test only because you need a test. Write a test to assert correct code. Testing is also not about 100% coverage. It's about asserting thecorrect working of the expected flow of events. But that is not the topic here. Jul 11, 2013 at 16:07

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.