My point is adding unit test for existing java file should be separate task, it should not block developers to change java file. As I said before, we should file a bug for each java file which doesn't have unit test, and arrange resources to fix these bugs.
Anthony > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Friday, February 08, 2013 12:19 PM > To: Anthony Xu > Cc: cloudstack-dev@incubator.apache.org > Subject: Re: [MERGE] Security Group in Advanced zone > > On Fri, Feb 08, 2013 at 11:43:52AM -0800, Anthony Xu wrote: > > I see your point, I think it should be case by case, > > > > In this feature, 100 line change are in 6 "manager" class, there is > no unit framework for them, to be honest, I don't know to create the > unit framework for manager class, I believe it is a big task. If the > framework is there, I'm glad to add test cases inside framework to test > the path I changed. > > > > If every function change needs unit test change, and as you said > there is <1% unit coverage. This will be a big burden for developer, > may slow down development. We may need to balance between them. > > So if we don't start doing this now, when will we start? I hope you > get > my point here... yes, things slow down, but then they speed up. Test > coverage is critical to rapid development in such a large community. > > -chip
