cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmad Emneina <>
Subject Re: unit tests guidelines...
Date Wed, 06 Mar 2013 03:53:21 GMT
+1 to fostering guruism.

On Tue, Mar 5, 2013 at 5:42 PM, 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.
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message