+1 to fostering guruism.
On Tue, Mar 5, 2013 at 5:42 PM, Alex Huang <alex.hu...@citrix.com> 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. > > 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 >
