What does unit testing mean to you?

Question

G'day,

I am working with a group of offshore developers who have been using the term unit testing quite loosely.

Their QA document talks about writing unit tests and then performing unit testing of the system.

This doesn't line up with my interpretation of what unit testing is at all.

I am used to unit testing being a test or suite of tests that are being used to exercise a single class, usually as a black box. The class under test may require other classes to be included by the implementation but generally it is a single class that is being exercised by the unit test(s).

Then you have system functional testing, intergration testing, acceptance testing, etc.

I want to know is this a bit pedantic on my part? Or is this what you think of when referring to unit tests and unit testing?

Edit: Rob Wells. I need to clarify that approaching such testing from a black box perspective is only one aspect. When using mock objects to verify internal behaviours, you are really testing from a white box perspective because you know what you want to happen inside the box.

Answer 1

Unit tests are generally used by developers to test isolated sections of code. They cover border cases, error cases, and normal cases. They are intended to demonstrate the correctness of a limited segment of code. If all of your unit tests pass, then you have demonstrated that your isolated segments of code do what they are supposed to do.

When you do integration testing, you are looking at end-to-end cases, to see if all the segments that have passed unit testing work together. Functional testing checks to see if the code meets the requirements as specified. Acceptance testing is done by end users to see if they approve of the final product.

Answer 2

I try to implement unit tests to test only a single method. and I make an effort to crete "mock" classes for dependant classes and methods used by the method I am testing... ... so that the exercise of the code in that method does not in fact call code in other methods the unit test is not supposed to be "Testing" (There are other unit tests for those methods) This way, a failure of the unit test reliably indicates a failure of the method the unit test is testing...

Mock classes are designed to "simulate" the interface and behavior of dependant classes so that the method I am testing can call them and they will behave ina standard, well-defined way according to system requirements. In order to make this approach work, calls to such dependant classes and to their methods must be made on a well defined interface, so that the "tester" process can "inject" the Mock version of teh dependant class into the class being tested instead of the actual production version... . This is kinda like a common design pattern referred to as "Dependency Injection", or "Inversion of Control" (IOC)

There are several third party tools on the market to help you implement this kind of pattern. One I have heard of is called "Rhino-Mock" or something like that...

Edit: Rob Wells. @Charles. Thanks for this. I'd forgotten using mock objects to completely replace using other classes except for the one under test.

A couple of other things I've remembered after you mentioning mock objects is that:

• they can be used to simulate errors being returned by the included classes.
• they can be used to raise specific exceptions to check exception handling in the class under test.
• they can be used to simulate items where setup costs are high, e.g. a large SQL DB back end.
• they can be used to verify the contents of an incoming request.

For more information, have a look at Martin Fowler's paper called "Mocks Aren't Stubs" and The Pragmatic Programmers's article "Mock Objects"