Bug fixes usually follow the method of, if a test already exists then you extend the test to show the bug and then you fix the bug. So from a regression point of view you should never get hit by that bug again.
The grey area is definitely around bug fixes for code that does not have a test. In an ideal world you would say "add a test module", but to start with it might be to much work when the important aspect is to get the bug fixed. But again you can develop test modules to help track down and find a bug, if it turns out you developed more test modules than you needed to fix the bug then the benefit is still there for the project. Just as a reminder this does all require a test tool/framework/environment that is easy to develop, execute and get results from quickly, otherwise it'll be painful and won't get much support. Ray Jacques Le Roux wrote: > From: "Ray" <[EMAIL PROTECTED]> >> I think it is wrong to suggest you will get less contributions. Once a >> test framework and structure is in place writing tests as you go takes >> no longer than the development and manual test process, and often it can >> reduce the time. I think for more people its a mind set adjustment, but >> it means you do more structured testing at the point of development >> rather than come back days/weeks/months later to find that obscure bug. > > I was playing devil's advocate to have more comments, got one elaborated > so far, thanks Ray ! :o) > >> There is a transition period that will be a little bumpy as people >> adjust but and as you say sensible decisions need to be made about what >> contributions require a test module like new features, bug fixes, >> enhancements etc. > > New features is obvious, depending on the shift, enhancements may > require, I think bug fixes should not. But I'm newbie in Continuous > Integration so I may be wrong. > > Jacques > > >> Ray >> >> >> Jacques Le Roux wrote: >>> Yes and there one day hopefully we will be able to run some type of >>> Continuous Integration. At ASF most projects use Hudson >>> http://en.wikipedia.org/wiki/Continuous_Integration >>> http://martinfowler.com/articles/continuousIntegration.html >>> http://wiki.apache.org/general/Hudson >>> >>> Of course before that, as Adam outlined, we would have to have a more >>> reliable set of tests. >>> Maybe, as David suggested, we could enforce our rules about that (no new >>> features without tests). >>> I'm afraid this would drastically reduce contributions. Maybe it's >>> better to have less but more robust. >>> >>> I agree that we need marketing, and I think we need as much tests. >>> >>> Jacques >> > >
