cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <HTrippa...@schubergphilis.com>
Subject RE: Master broken
Date Tue, 09 Apr 2013 08:57:48 GMT


> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@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.childers@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 :-)

Mime
View raw message