Satheesh Bandaram wrote: > Thanks for raising test failure issues. I do agree test failures > should be addressed quickly. > > I also want to suggest some ways to make sure a failure is not caused > by your own changes... Feel free to add any other suggestions you or > others may have. With so many changes going into derby, some small > number of failures are bound to happen. I believe Tomohito's changes > also got delayed because of test failures, not related to his changes. > > 1. Check the nightly reports > (http://incubator.apache.org/derby/derby_tests.html) If you see > same failure there, it is probably not caused by you. Still > suggest alerting derby-dev, so someone would address them. > 2. Run the test with and without your changes. Most offen if the > test fails the same way, it might not be your problem. > > I am sure there are more tricks out there...
In the prevention category ... There are several types of failures that have been common because they can occur even if the developer runs derbyAll in their own workspace and it passes. 1) Not performing svn add on new files. 2) Not performing svn propset svn:eol-style native on new files. 3) Not updating multiple masters. I wonder if 1-3 could be mitigated by some simple script that would check for these red flag conditions that could be run by both contributor and committer. 4) Introducing platform specific failures. I think that we just have to deal with these and try to resolve them quickly. 5) Introducing Intermittent test failures because expected output is printed to System.err. The test harness redirects all output from System.err and System.out to the same file. This can cause timing related diffs. All expected output should go to System.out. Sorry again about testij. Kathey
