On 03/06/2013 02:42 AM, Alex Huang wrote:
With the discussion in the BVT thread and other evidence from the check-ins, I
think there are some confusion on when to and what to write in a unit test.
Unit tests are a philosophy thing and I usually stay away from things like
that. If you are interested in writing the right type unit tests, here's my
$.02.
Thanks for your input! Writing good tests is indeed a challenge, but
definitely worth it, although I'm not a guru-status yet.
Wido
Unit tests are for
- Guaranteeing the component is upholding its contract.
- Illustrating how the component is to be used.
- Mocking up failure scenarios
- Explaining something that people might not understand if they look
inside your code.
When to write a unit test:
- Write it at the component level because that's where the value is.
You can test everything under the sun but basically code changes all of the
time. What you really want
- Write it for an interface. For example, if you have AgentManager
and AgentManagerImpl, the methods you should test is in AgentManager. And a
lot of this goes back to your design. I have seen quite a bit of code that
just adds all the methods from the class to the interface. It's just something
you do rather than something you think before doing. That's just wrong and it
increases the number of unit tests you have to write.
These are usually what you need to test for when writing unit tests.
- Errors in the incoming parameters...<no duh!>
- Different positive paths for your code...<to state the obvious>.
- The one that people don't seem to do is to inject results into the
components that the component being tested is dependent on. This forces
component being tested to travel a different path. Most people recognize
incoming parameters causing a different path but does not recognize that
results from the components being used can cause a different path.
How to recognize a good unit test?
- The mock objects do not always return true or positive result.
- The unit test sets something for the mock object, test the method;
sets something else for the mock objects and then test the method again. This
means the tester is testing the component handling different returns from the
components it is using.
- The unit test makes a call to the component, and checks the mock
object to see if certain things are called. White box testing there.
- The unit test has asserts for catching exceptions or negative
returns (negative paths are tested)
- The unit test has comments that tell you what and why you're testing
- The unit test asserts tells you why the assert should not fail
- You won the blame game by saying look I have a test case for exactly
that.
Misconceptions about unit tests.
- You only write it when you write the component. Actually, a good
unit test is one that's progressively built up. You found a bug, you write a
test to make sure the bug is fixed. If you've gotten to that stage, then
you've pretty much reach guru status.
--Alex
