Open
Conversation
or at least one failure) rather than void.
classes. Took out optimization that says if two objects aren't the same class, they can't be same().
(Why does this need to be hard-coded into the Tester at all?)
"objects of different classes can't be same()", I didn't notice that some of the comparison code assumed both objects had already been confirmed to be the same class. As a result, comparing an object of a class with no fields with one of a class with fields could either pass or crash, depending on the order. Fix: put back in the "if (sameClass)" test, but applying only to a smaller section of code, so it's still possible to override this rule with same().
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changed the public "runWhatever" hooks in the Tester class to return true (if there were no errors) or false (if there was at least one), so "runWhatever" can be composed with other things. Such as, for example,
junit.framework.TestCase.assertTrue (Tester.run(new Whatever()));
so failed Tester cases show up as failed JUnit cases (in IDE's that support JUnit).
This should be backwards-compatible: any code that was calling Tester.run on the assumption that it returned void should still compile and run.
Alternatively, perhaps these should return an int (the number of errors encountered), which I guess would be even more informative.