One of the things that I want to focus on for the next couple of months is unit testing fundamentals. I want to really understand how to use it in my development and design process. I think one of the main questions that is always asked is what is unit testing. So in this blog, I want to discuss the what of unit testing. In my next blog post I will outline why you should unit test.
I try to explain unit testing as code that is written to verify that another unit of code is working correctly. For example this unit of code could be some business logic. The unit tests or test case would verify that the business logic is correct. I believe that for it to be unit testing it has to use a testing framework like nunit or junit. So just writing a console app to display value is not unit testing.
In the past, when I needed to determine if a unit of code was working correctly I would use one of the following methods: Run the debugger through the code line by line, create a simple console application to prove that the code works, or use a logger to write out the results to a log. Each of these methods work but are not always repeatable.
You would not want to run in debugger mode all the time to verify that your code works. With a console application, this code would need to be removed before you deploy--that is if you like clean code. Also you would need to recreate this console app each time you wanted to test. The trouble I have with using a logger for debugging or testing is that this code stays in your production code. Before you deploy the code you have to remember to comment out the code. Then if you need to test something, you have to uncomment the code. Additionally, you have to visually check the log to make sure the result is correct.
So with a testing framework you can create repeatable test that never go way. These test are created outside of the core code. You do not have to include lines of code for logging results to a log and forgetting to uncomment it. Also testing frameworks provide you a testing console or test runner. By using the test runner, your unit testing is also automated. With a click of a mouse button, you can quickly run all your test without having to run step by step in debugger mode. That would take some time if you had a large code base. By doing unit testing, it is as simple as creating a console application or line of code to return values to a log. A testing framework also provides you a way to verify the results with assertions. Assertion are provided from the testing framework via an Assert class.
As you continue to build your repeatable unit test, another form of testing develops. This testing is called regression testing. Regression can happen when you start to refactor your code for improvements. What can happen is that your change creates a bug. It may be that your refactor works for the code you changed but without the unit test running you never catch the bug somewhere else in the code base. By running your unit test you catch this new bug.
The last point I would like to make is unit testing is not the same as integration tests or system testing. Integration testing is testing of groups of unit code. A group of unit code could be a module that performs some kind of complex task. This type of test comes after unit testing. Next is system testing which tests the complete integrated system.
I would welcome any feed back on this post. This is post was to help me define unit testing.