These issues are caused by that some of components are not really mocked, instead, they are loaded directly main source.
One of the benefits from Spring is that it integrates with Mokito nicely, all we need is to probably have a base test configuration that returns all mocked DAOs or other common components and then have all unit test purely written against mocked components. We need to finalize the way to write Java unit test so that everyone can follow to reduce the frequency/prevent these from happening. I'll find some time to update the Unit-test guideline document in wiki, cleanup things in this area and re-enable all unit tests in the build. Kelven On 4/9/13 1:57 AM, "Hugo Trippaers" <htrippa...@schubergphilis.com> wrote: > > >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Monday, April 08, 2013 3:51 PM >> To: dev@cloudstack.apache.org >> Subject: Re: Master broken >> >> On Mon, Apr 08, 2013 at 07:44:41AM +0000, Hugo Trippaers wrote: >> > >> > >> > > -----Original Message----- >> > > From: Chip Childers [mailto:chip.child...@sungard.com] >> > > Sent: Saturday, April 06, 2013 7:16 PM >> > > To: dev@cloudstack.apache.org >> > > Subject: Re: Master broken >> > > >> > > On Sat, Apr 06, 2013 at 05:27:11AM +0000, Prasanna Santhanam wrote: >> > > > Ah - misunderstood. Like Hugo said, a test that fails on presence >> > > > of db >> > > connection should solve this. But I hope ppl will turn mysql on (as >> > > an additional step) to run the bvt. Or better yet, I can look into >> > > those db tests and port them as marvin tests. >> > > > >> > > >> > > Perhaps I'm confused, but having a unit test that fails the build if >> > > MySQL is running on the local machine seems like a really bad idea. >> > > >> > > I think the problem to solve is just that we want to avoid unit >> > > tests that require a DB. As long as we all know this, and that we >> > > have build jobs that fail on the CI side of things, isn't that >>enough? >> > > >> > > Am I confused? >> > >> > No :-) >> > >> > The idea is to avoid unit tests that rely on the DB. However this is >>rather >> difficult to do in some cases. We have a lot of autoloading going on, >>so in >> some cases a simple fix to components could suddenly result in having a >> component that requires a database connection. If the developer in >>question >> has an active database, he/she will never notice until the tests hit >>the master >> branch and Jenkins starts complaining. >> > >> > My idea was to solve this by adding a negative test (break if you have >> database) to give people a reminder (by breaking their build) if they >>have an >> active database. That could help developers remember to shut it down >> before compiling. >> >> I'm against this. It shouldn't be a build requirement to *not* have a >>DB >> running. That would be exceptionally complicated for people to deal >>with all >> the time, just to avoid inappropriate unit tests. > >That's a good point :-) I was also having mixed feelings about this, >just trying to help people remember that they should build unittests that >don't rely on the db. > >I'm dropping this suggestion :-)
