unit tests

Adam Young ayoung at redhat.com
Mon Jul 12 19:54:01 UTC 2010


On 07/12/2010 03:47 PM, Jesus Rodriguez wrote:
> While working in ConsumerResourceTest recently, I noticed that
> it requires the DB. I started thinking (yeah imagine that) :)
> that maybe we shouldn't require the DB for anything except
> the curators.
>
> Another thing I noticed is we have 3 ways of creating a
> test consumer:
>
> * direct ctor i.e. new Consumer(...)
> * TestUtil.createConsumer
> * consumerCurator.create(...)
>
> I prefer the first one or the second if it is used by many
> places aside from this particular Test class.  The only
> thing that should call the curators are the curator tests
> the rest should use mockito to mock them out.
>
> The ConsumerResourceTest requires a lot of infrastructure,
> like the database, curators, services etc. While guice makes
> some of this easier, it makes for a slow and brittle test.
>
> I replaced the testCreateConsumer (and 2 others) with mocks.
> http://pastie.org/1041394
>
> The original test 'looked' simpler: http://pastie.org/1041401
> but it relied on a lot of stuff from the @Before method.
> And the problem I ran into was that this test uses a
> StubIdentityService which does not behave like our
> DefaultIdentity Service adapter nor any other.
>
> My proposal is that we make the resource unit tests
> use mocks as much as possible to test the interaction.
> And the only thing that should use the DB should be the
> Curator tests.
>
> Thoughts? comments?
>
>    
I'm not on the project anymore, but I heartily endorse this approach. 
Testability is one of the best side effects of using GUice.



More information about the candlepin mailing list