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.
