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

Please allow Iterable as type for @DataPoints #126

Closed
jschneider opened this issue Jul 28, 2010 · 9 comments
Closed

Please allow Iterable as type for @DataPoints #126

jschneider opened this issue Jul 28, 2010 · 9 comments

Comments

@jschneider
Copy link

Often it is easier to just return a Collection that contains the data points. Therefore I think it will be helpful to allow additional return types for those methods.

I suggest Iterable, but at least Collection should be allowed.

@MatrixFrog
Copy link

Duplicate of issue 110 (but you're right, there's no reason to exclude Iterables as well).

@dsaff
Copy link
Member

dsaff commented Oct 24, 2012

Proposing for 4.12

@dsaff
Copy link
Member

dsaff commented Sep 4, 2013

@pimterry, am I remembering correctly that #651 fixed this?

@pimterry
Copy link
Contributor

pimterry commented Sep 4, 2013

Mostly #658 actually, but #651's involved too.

On a related note:

I'd actually thought that this was slowly migrating across to junit.contrib, so I'd been completely ignoring it for a while now really while that dust settled. Is there an ongoing plan for that?

Currently looks like it's got the 4.11 implementation, but none of the 4.12 bits yet. I assume the plan is to pull those changes across (e.g. the fix for this), tidy them up (i.e. fix #673) and then push a release, yes? (And then pull it out of JUnit proper).

If that's true and there's nothing else much going on on this now, I might try and take a look at sorting that out in the next month or so. Would that be useful?

@dsaff
Copy link
Member

dsaff commented Sep 5, 2013

Great, that's what I thought.

On your related note:

@pimterry, yes, that's the medium-term plan (since getting theories Right involves either depending on things we don't want core JUnit depending on, or re-implementing things core JUnit has no business re-implementing.)

And help is definitely appreciated. Be sure to also check in with @pholser, who's done the bulk of the heavy-lifting thus far.

@dsaff dsaff closed this as completed Sep 5, 2013
@pholser
Copy link
Contributor

pholser commented Sep 9, 2013

Happy to start rolling 4.12-ish theory changes into contrib once 4.12 goes live.

@pholser
Copy link
Contributor

pholser commented Jan 15, 2014

@dsaff @pimterry Seems like 4.12-ish activity has slowed some, at least as it pertains to theories. I think I'll start pulling the theories enhancements slated for 4.12 soon.

@pholser
Copy link
Contributor

pholser commented Mar 29, 2014

@dsaff @pimterry As of this writing, junit.contrib's junit-theories (under pholser) has the changes that have occurred since 4.11.

@Stephan202
Copy link
Contributor

Just for reference: this issue was eventually resolved by #658.

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

No branches or pull requests

7 participants