Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

}
share|improve this question

6 Answers 6

up vote 7 down vote accepted

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

share|improve this answer

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.

share|improve this answer
    
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 '13 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.

share|improve this answer
    
Thanks for the reply. Could you please provide examples based on my code. –  Sunny Jul 11 '13 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. –  mortalapeman Jul 11 '13 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.

share|improve this answer
    
Just because an automated test is not a unit test it does not mean it will not be useful. –  Doc Brown Jul 11 '13 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. –  Rob van der Veer Jul 11 '13 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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