cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: Unit tests
Date Fri, 09 Nov 2012 20:19:26 GMT
> >> 2 - Do we want to get stricter about what exactly is considered to be
> >> a unit test (vs an automated test that may or may not be based on the
> >> junit framework)?
> >
> > I actually consider db tests to be unit tests as long as the db is setup and
> cleaned up by the unit test itself.
> Having a real DB as a requirement for low level unit tests does two
> things that I don't like.
> First, it requires the configuration of a database (in our case,
> MySQL) as part of running the test.  That's a build dependency that
> (IMO) shouldn't be needed.
> Second, configuring and using a real database significantly slows down
> the unit test process.  For unit tests to be useful, they have to be
> as fast as possible.  We simply don't have enough unit tests for this
> to be a major problem right now, but as the coverage increases (true
> unit tests, not integration tests) this will get much worse.
> In my ideal world, unit tests are limited in their test scope to only
> cover code within a particular object (inherited or directly
> accessed).  Imported objects should usually be mocked.  We might be
> arguing about nuance of definition here, but I've always tried to keep
> a bright red line between unit and integration tests.  Both matter,
> but they test different things.

Actually, you and I are not that far apart.  I'm thinking mainly in terms of testing code
that are actually accessing database.  For example, the unit test is to ensure a search query
returns the results that are intended.  You can't really mock those up.  

For code paths that are not testing search queries but are just dependent on search results,
I agree with you.  Just mock up the DAOs.


View raw message