Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #449, stopping AllMembersSupplier & Theories hiding DataPoints method exceptions #639

Merged
merged 5 commits into from
Mar 26, 2013

Conversation

pimterry
Copy link
Contributor

This also includes a rewrite of the Theory nullsAccepted code, since that relied on the previous behaviour of this. It's now just a synonym for Assume.assumeNotNull(params[]), and is handled in the Theories runner itself, which seems much nicer to me.

Some of the code around this has a good few discrepancies in how it handles datapoint array methods vs single datapoint methods, which make this a little messy, but I'm going to look at fixing these at a later stage and I've left them as they are. I've filed issues for them for now, as #637 and #638.

@dsaff
Copy link
Member

dsaff commented Feb 18, 2013

I'm sorry to say, but as I've finally caught up and indicated at #449, this bug/missing feature was in the design phase, so we'll need to figure out some way to have users request the new behavior.

@pimterry
Copy link
Contributor Author

Hmm. That's going to be quite untidy to implement, and a) this is in experimental anyway, b) I think very very few people are going to go out of their way to enable datapoint exception failures if we do add that, even though they should, and c) I really don't think there should be anybody intentionally relying on datapoint methods failing to return values, even if the implementation has allowed that for now.

Could we go for the compromise you've proposed on an older pull-request relating to this at #328 (comment)? I.e. instead add an opt-out option as a @DataPoints parameter, to ignore failures with a given exception type? With that we'd change the default behaviour, but leave an easy option for people to get out of it if it actually causes anybody problems. Would that be more acceptable?

@Stephan202
Copy link
Contributor

I could get behind the proposed compromise.

Please note that the current situation is pretty bad: If one has multiple @DataPoints for the same value type, then an exception in one might go completely unnoticed, since (by virtue of there being data points generated by some other method) the @Theory-annotated tests will run just fine.

Even when there is only one @DataPoints-method, a failure in said method is hard to track down. Users shouldn't have to attach a debugger just to figure out which piece of code throws an exception.

So yeah, the suggestion in #328 sounds pretty good by comparison :)

@dsaff
Copy link
Member

dsaff commented Mar 11, 2013

OK, I can be reasonable on a good day. :-) If someone can put up a public notice about the suggested change on junit@yahoogroups.com, and no one complains for ~48 hours, we can go for the #328 compromise.

…thod exceptions

Also includes a rewrite of the Theory nullsAccepted code, since that relied on the previous behaviour of this.
@pimterry
Copy link
Contributor Author

Posted a message to the mailing list on wednesday (http://tech.groups.yahoo.com/group/junit/message/24356) and got no responses, so I've now added a fix along the lines of #328. DataPoint and DataPoints can now be given an ignoredExceptions list, and any exceptions thrown that are instances of members of that list will not fail tests. Better?

@dsaff
Copy link
Member

dsaff commented Mar 21, 2013

@pimterry, thanks. Can you merge with HEAD?

@pimterry
Copy link
Contributor Author

Merged.

DataPoint annotation = fMethod.getAnnotation(DataPoint.class);
if (annotation != null) {
for (Class<? extends Throwable> ignorable : annotation.ignoredExceptions()) {
Assume.assumeThat(t, not(instanceOf(ignorable)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clever.

@dsaff
Copy link
Member

dsaff commented Mar 22, 2013

This is really good. Just one request, and we're good to go. Thanks.

dsaff pushed a commit that referenced this pull request Mar 26, 2013
Fixes #449, stopping AllMembersSupplier & Theories hiding DataPoints method exceptions
@dsaff dsaff merged commit 34e6674 into junit-team:master Mar 26, 2013
@dsaff
Copy link
Member

dsaff commented Mar 26, 2013

Thanks for this. Can you update the release notes?

@pimterry pimterry deleted the datapoints-exceptions-#449 branch March 26, 2013 17:54
@Stephan202
Copy link
Contributor

For reference: this change has been documented in the release notes in the interim.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants