unit testing Wednesday, June 14 2006
This brief article covers concepts behind unit testing. Unit testing is critical part when application grows, when we do small changes in application, which needs to be tested in all the flow. To make the job easier and minimizing the risk of unforeseen side effects, Unit testing is a useful safeguard.
Once I finished code for a class, I usually write test cases for each methods in the class. Including protected and private methods. Latter when I have complete component (one or more classes) I test all the classes in the component. We have few approaches.
1) Write a full class and then create Unit test
2) Write a class method and test that method at a time
3) Write a test first, and write the required class next (eXtream Programming!)
In Recent projects I started to follow the third approach. It’s really helpful approach, below are the advantages
-It forces me to think what and how the client needs the class. Also avoids additional functionality that never used.
Once we write tests, and proceed to run all the tests. (I would write a separate brief article about how to write a Unit test with an example. There are two options available - 1. Using testing tools and frameworks (JUnit, Nunit VSST etc), 2. manually writing code to test (more flexible but time consuming)
Getting ready for Unit testing: Before start, we need test data to test expected and unexpected results. First we need to understand about data, its range, how it validated in UI or component in case of data is passed from other systems, analyses how the data is passed to method and need to see it from users perspective. These are few things I usually follow before start the Unit test.
Sometimes, any changes in code would break unit testing, so whenever any tests fails first we have to test whether the fault is in application or in the test. If the test case is fault then we have to rewrite the tests, rewriting of test is called refactoring. It’s a tiresome work, but maintaining the validity of tests is important. Automating the process would reduce the time and improve the process.
To test components which are having core business logic or reused in number of places, I recommend to test using persistent data.
There are situations where unit testing is very hard to do. Example: multi-threading applications, windows services etc. My current project involved lot of threads, I switched off all threads and tested one thread at a time and tested with all threads, took lot of time and effort. I am not sure how much efficient to use automated tools to test these kind applications.
Unit testing in distributed systems is little tricky; we have to duplicate the other system by writting the output to a file instead of sending to other system and passing the required parameter from local application or from file or any other local resource.
These tests give me confidence to check in and makes QA’s job easier. Rarely I got nasty surprises from production. For each built I run all my unit tests, whether the change is belongs to current code or not. I didn’t do any documentation for Unit testing due to time constraints. Good documentation allows improving maintenance when the original developer has left the project or the company.
There are couple of questions, to get better idea about Unit Testing.
1) Is unit testing is low level or high level testing? Ans: Low level
2) What is the difference between Unit test and Acceptance Test? Ans: Both are complement each other. Acceptance test usually done by QA team, to check whether it meets all use cases. Unit testing is by done Developer and its low level, white-box testing. Unit test can’t replace Acceptance Test.
Impacts when Unit testing is not followed:
Costs more to correct errors discovered in later project phases and all other side effects. A small single issue may introduce lot of other problems, even it worse the situation if the system is integrated with other systems.
Ok. I would keep write about my testing experience and knowledge.
