> -----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 :-)
