> -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Friday, November 09, 2012 9:19 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Unit tests > > > >> 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.
This depends on the point of view. We don't need to test if the database is actually returning the right answers. I trust the mysql guys to take care of this part. In this example the unites could be to see if the SearchBuilder contains the correct parameters based on the objects we passed into it, as the SearchBuilder is something that we should check. Maybe even check if the resulting query is as expected and the correct parameter set. This is more work than just sending the query to the database, but provides more fine grained details on the unittests. If you use the database, you are not only testing the unit being tested but also the database, the procedure used to setup the database and any previous steps done using that database. In which case a failure of the unittest will not even tell you where the failure occurred, it could be in any of the mentioned components, which in my view defeats part of the purpose of a unittest, which is the ability to directly pinpoint a class with a failure. Hugo > > 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. > > --Alex
