This content has been marked as final. Show 6 replies
I'd like my FreeBSD port --The test has some value for us because it checks an edge case we're concerned about, and we've gotten used to understanding on our own machines whether the failure is an issue or not. It was a tough case to mimic, which is why there are some intermittent failures. But you have a good point here.
http://www.freshports.org/java/berkeley-db -- to run
these tests automatically after building, so that the
user can be sure, her/his development platform is
While we'll leave it in the code base, we'll take it out of the default test target in the build file in the next patch release, and we'll put it into one of our meant-for-internal-use test targets. In the meantime, would it work for you to manually remove that specific test from your port?
The test has some value for us because it checks an edge case we're concerned aboutCould it, maybe, just report the value without making a judgement on whether it is a failure or not?
In the meantime, would it work for you to manually remove that specific test from your port?Yes, it would -- how can I do that?
Could it, maybe, just report the value without makingYes, that's a good option too. I'll look at our internal test targets and figure out which one is better -- moving that test case or changing the assertion to a warning.
a judgement on whether it is a failure or not?
That particular file, com.sleepycat.je.recovery.CheckpointActivationTest.java, has two test cases. You could choose to edit the file and delete the problematic case (testLogSizeBasedCheckpoint) by literally removing the method, or you could rely on the fact that junit identifies test cases by naming convention. In other words, you could simply edit the file to rename the method testLogSizeBasedCheckpoint to something that doesn't start with the prefix "test", like "disabledTestLogSizeBasedCheckpoint" and junit will no longer run that test.