While I really like the idea of including a unittest with every commit, I don't feel very comfortable with doing this right now. The current code coverage is pretty low and just adding new unittests for commits might even give a false sense of security. Next to that, enforcing this through technical means might prevent people from participating as we make the bar higher for anybody willing to join. I'd rather have somebody submit a patch without a unittest and having to do it myself, than not receiving the patch at all.
I think the way forward would be to devote serious effort to get the current code base covered with unittests first. That way we will gain the much needed confidence in the current code, which means that we can more easily integrate changes coming in from other branches and from reviews and still have a level of certainty that stuff still works. Next to that it will provide an enormous amount of example code for would be committers and people sending patches. For a lot of people it is much easier to adapt an exisiting unittest then creating a new one from scratch, especially with a complex code base like ours. Custom injection code (like ComponentLocator) requires some knowledge to work into unittests and might be a tad difficult for people not intimately familiar with it. We as the committer team should be able to govern ourselves and take the responsibility to start including unittests for exisiting code. If we can't agree to get this done as a community, implementing a technical solution will not help, but probably have the opposite effect of alienating the people. And that is something that we should not want. Cheers, Hugo > -----Original Message----- > From: prasanna [mailto:[email protected]] > Sent: Saturday, November 10, 2012 5:30 PM > To: [email protected] > Subject: Re: [DISCUSS] All checkins must include unit testing > > I like the idea of unittests with every commit. > > A few related topics I have that might be worth considering in this > discussion: > > 1) What about unittests for the existing code? Or do we fill that gap slowly? > 2) Minor but we should probably update the unittesting wiki on how to > mock our managers, daos etc? > > And a few things I'm confused about: > > 1) Gerrit is a code review tool just like reviewboard? So - would it really > serve the purpose if committers can still check-in without unittests? > 2) Or do we enforce everyone to send in for gerrit review? That seems > counter-intuitive to the idea of committer-ship? > > -- > Prasanna.,
