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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement ValueSource on fixture constructor parameters #2673

Open
jnm2 opened this issue Jan 20, 2018 · 4 comments
Open

Implement ValueSource on fixture constructor parameters #2673

jnm2 opened this issue Jan 20, 2018 · 4 comments

Comments

@jnm2
Copy link
Contributor

jnm2 commented Jan 20, 2018

What do you think of allowing ValueSource on each param of a fixture constructor? It seems more consistent with test methods.

Posted by @CharliePoole:

My first reaction was "We have an issue for that!" but I can't find one. 馃槥

We had lots of discussion of this in the past. We were going to implement parameterized fixtures in three stages: (1) like TestCase, (2) like TestCaseSource and (3) like Values, Random, etc. together with the various combining strategies.

As far as I can see, the issues were all closed after we did (1) and (2) and we just stopped tracking (3).

I'm not sure how or if that would solve the current issue but I think it's a feature we should have and is worth its own issue.

@CharliePoole
Copy link
Contributor

@jnm2 Don't want to meddle but... 馃槇

I'd call this a feature rather than an enhancement. In any case, I'm glad you didn't call it an idea, which would mean to me that we don't know whether we want to do this at all. I'd even call it a high prioirity feature, except I worry that we end up with too many of those to work on.

However, as I interpret our labels, putting the design label on it and not assigning it to yourself means you are waiting for somebody else to take responsibility for the design. Is that your intent?

I think we often do this and end up just spinning our wheels. I think somebody actually has to be in charge of coming up with a design, either through discussion or by drafting something. That person is the one who pulls us back on track when we get off it... "Is this relevant?" etc. Everyone else is free to be pretty loose about things, but that guy has to take charge.

I say all this because I read your comments in the original issue as this being something you wanted to do and it seems like a good idea to me.

@jnm2
Copy link
Contributor Author

jnm2 commented Jan 20, 2018

Yay, I was worried that is:feature and putting it on the backlog would be too forward! 馃槂 To me it's pri:normal because we aren't sure it's blocking anyone. I am taking a break from assigning myself to pri:normal issues unless they're tiny, until this list gets shorter 馃槼:

@CharliePoole
Copy link
Contributor

Ah my comment was confusing because I didn't notice you had it as a discussion! That's only visible when you are using ZenHub, so I always try to couple it with is:idea, thereby allowing non-users of ZenHub to see what's going on. BTW, when on the phone, which is a lot of the time these days, nobody is a ZenHub user.

@ChrisMaddock
Copy link
Member

Heh, what are the chances. I was just about to file this, after writing this:

    [TestFixture("MIN", BlockSize.FULL)]
    [TestFixture("MAX", BlockSize.FULL)]
    [TestFixture("MIN", BlockSize.PARTIAL)]
    [TestFixture("MAX", BlockSize.PARTIAL)]
    [TestFixture("MIN", BlockSize.DECIMAL)]
    [TestFixture("MAX", BlockSize.DECIMAL)]

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

3 participants