cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmad Emneina <aemne...@gmail.com>
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 <Alex.Huang@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
>

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