introduce pytest.Marked as holder for marked parameter values #1921

RonnyPfannschmidt · 2016-09-07T09:04:17Z

this pr introduces a actual real type to separate parameter values and marks

this enables having functions as parameters with marks

it currently mirrors the broken mark overriding of the nested mark extraction code in place

documentation and examples upcoming

coveralls · 2016-09-07T09:38:13Z

Coverage increased (+0.007%) to 93.083% when pulling 25ea19e on RonnyPfannschmidt:marked-value into 1c9bd92 on pytest-dev:features.

coveralls · 2016-09-07T09:58:43Z

Coverage increased (+0.007%) to 93.083% when pulling af6a3ea on RonnyPfannschmidt:marked-value into 1c9bd92 on pytest-dev:features.

coveralls · 2016-09-07T10:16:32Z

Coverage increased (+0.007%) to 93.083% when pulling 431bd2b on RonnyPfannschmidt:marked-value into 1c9bd92 on pytest-dev:features.

flub

So I guess you want to deprecate pytest.mark.foo on a parametrised value? This seems rather API heavy and I'm not sure I'd like to explain to people why we have two different ways of marking things. What's the main thing you're trying to address with this change?

RonnyPfannschmidt · 2016-09-19T12:18:10Z

@flub the current way is seriously broken - its impossible to pass a function for example
marks should never ever made it to be used that way

the code that enables it is a painful hack i want to see gone

pytest.mark.foo is something we apply to functions, not to values

its a different type of behavior, and it breaks horrible

flub · 2016-09-19T14:28:22Z

Ah, I see what you mean. I must admit my first reaction on marking a parameterised value with skipped was hesitation as well but then practicality seemed to beat purity.

But if we want to deprecate that why not experiment with other APIs? how about for example:
@pytest.mark.parametrize('a', [1, 2, 3], markers=[None, pytest.mark.skipif, None])? I think i mainly feel that the pytest.marked() api you're proposing here is not really addressing all the problems with marking parameters.

RonnyPfannschmidt · 2016-09-19T14:32:05Z

well, you can have single and multiple marks per value, and not all values have marks
so adding yet another list is a pain (from my pov)

flub · 2016-09-19T14:38:28Z

Any other creative alternative? How about @pytest.mark.parametrize(Parameter('name', 'id', marks=[a, b]), ...)?

I realise I'm just throwing kind of random things at this but if changing the API anyway it's a good idea to brainstorm about how to create the best API with the requirements we know now.

The-Compiler · 2016-09-19T15:04:02Z

I don't really like the idea of having another list either - Parameter sounds interesting though, especially because it provides an alternative to ids as well.

I think that'd be really useful, for example in this qutebrowser test where it's tricky to keep the ids lined up with the tests:

    @pytest.mark.parametrize('code', [
        str,
        lambda e: e[None],
        lambda e: operator.setitem(e, None, None),
        lambda e: operator.delitem(e, None),
        lambda e: None in e,
        list,  # __iter__
        len,
        lambda e: e.has_frame(),
        lambda e: e.geometry(),
        lambda e: e.style_property('visibility', strategy='computed'),
        lambda e: e.text(),
        lambda e: e.set_text('foo'),
        lambda e: e.insert_text('foo'),
        lambda e: e.is_writable(),
        lambda e: e.is_content_editable(),
        lambda e: e.is_editable(),
        lambda e: e.is_text_input(),
        lambda e: e.remove_blank_target(),
        lambda e: e.outer_xml(),
        lambda e: e.tag_name(),
        lambda e: e.rect_on_view(),
        lambda e: e._is_visible(None),
    ], ids=['str', 'getitem', 'setitem', 'delitem', 'contains', 'iter', 'len',
            'frame', 'geometry', 'style_property', 'text', 'set_text',
            'insert_text', 'is_writable', 'is_content_editable', 'is_editable',
            'is_text_input', 'remove_blank_target', 'outer_xml', 'tag_name',
            'rect_on_view', 'is_visible'])
    def test_vanished(self, elem, code):
        """Make sure methods check if the element is vanished."""
        elem._elem.isNull.return_value = True
        elem._elem.tagName.return_value = 'span'
        with pytest.raises(webkitelem.IsNullError):
            code(elem)

RonnyPfannschmidt · 2016-09-19T15:06:11Z

its relatively easy to add a name to a marked value as well

parametrize('a', [pytest.marked_value(name='tricky', marks=[pytest.mark.xfail, pytest.mark.long_running], value=42)])

RonnyPfannschmidt · 2016-09-19T15:07:34Z

we chould also extend the marked_value mechanism to a general annotated value

then users can put test ids# names, marks and whatever they want in

flub · 2016-09-21T09:24:27Z

Another use-case I got reminded off via another issue is that you can have ids to be a callable currently I think?. The "marked value/param object" approach might make that one tricky.

The-Compiler · 2016-09-21T09:34:03Z

we chould also extend the marked_value mechanism to a general annotated value
then users can put test ids# names, marks and whatever they want in

That sounds like a quite confusing API, which adds another overload for the word mark. I really prefer @flub's suggestion about having a pytest.Parameter.

Another use-case I got reminded off via another issue is that you can have ids to be a callable currently I think?. The "marked value/param object" approach might make that one tricky.

Why? I'd guess the callable would just get the value (and not the Parameter object) like before? The only open question would be what happens if there's a Parameter('foo', id='bar') with ids=... (with either an iterable or a callable). I think in that case the one in Parameter should win, so you can have a callable for the generic cases and overwrite it when needed.

RonnyPfannschmidt · 2016-09-24T12:21:45Z

so can we get back to making this something directly usable - namely - giving values a set of marks

that part is solved, and the name should be discussed

i rather want to introduce a simple straightforward api now than try to get a more complete concept right (which usually fails for a few iterations)

flub · 2016-09-24T15:31:35Z

I'm not at all convinced that the idea of a "marked value" is a very simple and straightforward concept. I would actually have no idea what it is in isolation let alone guess that it is a way of being able to apply a mark to one of the generated test items/functions.

I think as the various parametrisation mechanisms have grown they have got weirder and weirder and are now really not as straight forward as might be desired for people new to it.

RonnyPfannschmidt · 2016-09-24T17:12:32Z

basically a marked value is intended to bring markers and parametrization together

perhaps it should be called marked_parameter instead of marked value,

in any case, what we currently have is broken and cant be fixed without breaking things worse

nicoddemus · 2016-11-09T01:44:17Z

Sorry for joining so late in the discussion.

I empathize with the fact that @RonnyPfannschmidt wants to solve the problem of "how to mark a value" quickly, but I also see the merits of the points raised by @flub and @The-Compiler that since we are introducing a new player into the mix (a "marked value"), we might as well discuss if we don't want to improve the overall API. We might arrive at something that not only fix how to mark values but also fixes some other problems/warts.

I agree that the current parametrization API might be a little awkward specially when multiple parameters, ids, and markers are involved. I like the Parameter idea at first sight and would like to see if we can evolve it a bit.

Here an example from the docs, adding ids for extra juice:

@pytest.mark.parametrize(("n", "expected"), [
    (1, 2),
    pytest.mark.xfail((1, 0)),
    pytest.mark.xfail(reason="some bug")((1, 3)),
    (2, 3),
    (3, 4),
    (4, 5),
    pytest.mark.skipif("sys.version_info >= (3,0)")((10, 11)),
], ids=['1-2', '1-0', '1-3', '2-3', '3-4', '4-5', '10-11'])
def test_increment(n, expected):
    assert n + 1 == expected

Is something like the following what @flub and @The-Compiler are thinking about?

@pytest.mark.parametrize(("n", "expected"), [
    pytest.param(1, 2, id='1-2'),
    pytest.param(1, 0, marks=pytest.mark.xfail, id='1-0'),
    pytest.param(1, 3, marks=pytest.mark.xfail(reason="some bug"), id='1-3'),
    pytest.param(2, 3, id='2-3'),
    pytest.param(3, 4, id='3-4'),
    pytest.param(4, 5, id='4-5'),
    pytest.param(10, 11, id='10-11', marks=pytest.mark.skipif("sys.version_info >= (3,0)")),
])
def test_increment(n, expected):
    assert n + 1 == expected

Surely it is more verbose, but I'm sure it is more natural to read and understand what's going on IMHO, specially for pytest beginners.

One thing that comes to mind is that the current ids parameter when given as a function: I understand most people use a short lambda for that, and since now the ids are passed to each pytest.param one has to define the lambda before the parametrization and reuse it.

fmt_date = lambda v: v.strftime('%Y/%M/%d')
@pytest.mark.parametrize('date', [
    pytest.param(date(2016, 11, 10), id=fmt_date),
    pytest.param(date(2016, 15, 10), id=fmt_date),
    pytest.param(date(2016, 21, 10), id=fmt_date),
])

But that is a minor inconvenience IMHO.

Another issue is that we probably don't want to let users mix styles... if one of the values is a pytest.param instance, IMO must check that they all are and the ids parameter to pytest.mark.parametrize is not given. Mixing both (at least initially) seems like to bring confusion to the users.

What are your thoughts?

The-Compiler · 2016-11-09T06:47:00Z

IMHO, combining pytest.param and ids should work - I don't see a reason to disallow something like:

@pytest.mark.parametrize('date', [
    pytest.param(date(2016, 11, 10), marks=pytest.mark.xfail),
    date(2016, 15, 10),
    date(2016, 21, 10),
], ids=lambda v: v.strftime('%Y/%M/%d'))

When ids is given and one of the pytest.param instances has id= used, then probably a failure makes sense.

Other than that, that sounds like a great proposal!

RonnyPfannschmidt · 2016-11-09T07:37:52Z

this is a entirely different concept, but it can be done relatively quickly, i#ll try to finish before the weekend

@nicoddemus did lay out things fabulously

nicoddemus · 2016-11-09T10:43:00Z

IMHO, combining pytest.param and ids should work

I thought about disallowing it at initially because:

It is easier to allow something later if we are OK with it rather than the other way around.
I thought it might be a little weird to allow pytest.param with id= plus the general ids= parameter:

@pytest.mark.parametrize('date', [
    pytest.param(date(2016, 1, 1), id='new years'),
    date(2016, 15, 10),
    date(2016, 21, 10),
], ids=lambda v: v.strftime('%Y/%M/%d'))

But after looking at the example itself I think it is pretty obvious that the param-specific id= takes precedence. 😉

Also, as I understand it the idea is to eventually deprecate the current way to mark parametrized values and eventually remove them in 4.0, so allowing users to mix the two styles is important to make it easy to adopt the new style because they only have to change the parameters that are marked to the new style, instead of all of them:

@pytest.mark.parametrize('date', [
    pytest.mark.xfail()(date(2016, 11, 10)),
    date(2016, 15, 10),
    date(2016, 21, 10),
])

To convert it when mixing the styles is allowed:

@pytest.mark.parametrize('date', [
    pytest.param(date(2016, 11, 10), marks=pytest.mark.xfail),
    date(2016, 15, 10),
    date(2016, 21, 10),
])

When it is not:

@pytest.mark.parametrize('date', [
    pytest.param(date(2016, 11, 10), marks=pytest.mark.xfail),
    pytest.param(date(2016, 15, 10)),
    pytest.param(date(2016, 21, 10)),
])

Depending on the values, a find/replace might be tricky as your example with lambdas suggest.

So in summary, I agree with you that we should allow mixing pytest.param with the current style. 😁

nicoddemus · 2016-11-09T10:47:20Z

this is a entirely different concept, but it can be done relatively quickly, i#ll try to finish before the weekend

Sounds good @RonnyPfannschmidt, but perhaps you should hold a bit to gather some more feedback? Particularly @flub which contributed a lot to the discussion already, but would love to hear from @hpk42 and @pfctdayelise as well.

hpk42 · 2016-11-09T11:41:37Z

I guess the pytest.param() or pytest.Parameter() helper function/Class to cleanly create values with meta-information and allowing a mix until 4.0 makes some sense. But I'd really like to see full documentation on this based on what @nicoddemus already posted. FWIW I guess it's not going to be a change that breaks too many people's code as marking parametrization values is not done that often. So warning with 3.1 and erroring out with 4.0 is probably ok.

The-Compiler · 2016-11-09T13:21:55Z

as marking parametrization values is not done that often

Hmm, I'm not so sure about that - if you use parametrization a lot (which I'd expect many testsuites to do), it's quite natural to want to xfail a single line there, no?

and allowing a mix until 4.0 makes some sense

Are you talking about marking parameters here, or also about ids? For ids, I think we should still allow mixing ids= with pytest.param().

RonnyPfannschmidt · 2016-11-09T13:30:11Z

well, we wouldn't remove the old way, just complain about it for a while

hpk42 · 2016-11-09T13:40:32Z

@The-Compiler yes, mixing with ids= makes sense to me especially since it can be a function as noted earlier. Basically the only thing that gets deprecated/removed at some later point is the usage of pytest.mark.* for parametrization values. In any case, i'd really like to see full documentation as part of this PR.

coveralls · 2017-01-19T10:17:50Z

Coverage increased (+0.001%) to 92.705% when pulling afa0450 on RonnyPfannschmidt:marked-value into 6c011f4 on pytest-dev:features.

RonnyPfannschmidt · 2017-01-19T10:18:51Z

@nicoddemus @hpk42 i updated/rebased the pr and would appreciate a second pair of eyes - i'd like to speed up landing this

nicoddemus

@RonnyPfannschmidt really sorry about the delay in getting to this! I really appreciate your effort in cleaning up how marks stick to functions.

Overall I like how this is turning out @RonnyPfannschmidt, but I think besides my comments we also need a prominent CHANGELOG entry and figure out how better add more documentation about this new and important feature.

nicoddemus · 2017-02-08T21:30:23Z

_pytest/mark.py

+        if isinstance(marks, MarkDecorator):
+            marks = marks,
+        else:
+            assert isinstance(marks, (tuple, list, set))


Since this assert is triggered directly by user input, should we raise an exception which doesn't display the internal pytest traceback? Maybe UsageError?

we have no sane mechanism for that point in time, as such i'd just leave the exception until we do get a way to sensibly report such errors

UsageError is not a good fit?

nope, its an error that does warrant to just stop collection alltogether

Unless I'm mistaken it seems that's what UsageError does, no?

whops, i forgot a "not" there

Hmm I disagree... if I type mark= instead of marks=, why would I not want a glaring and loud error at that? Do you have an example of where just emitting a warning makes sense?

i want a collelction error, not a direct stop of the process

Oh OK, I agree.

Now I see, I got confused by your comment on the line below:

while taking a look again, it may be sensible to trigger a pytest warning there

and thought you meant a warning here as well. My bad.

Having collection error at this point is definitely the proper approach. 👍

nicoddemus · 2017-02-08T21:31:06Z

_pytest/mark.py

+            assert isinstance(marks, (tuple, list, set))
+
+        id = kw.pop('id', None)
+        assert not kw, kw


Same here, a better message would be "Unknown keyword arguments: {}".format(kw.keys())

while taking a look again, it may be sensible to trigger a pytest warning there

Hmm I think it should break immediately. From my POV having **kwargs here is just a way to emulate the keyword-only syntax of Python 3, so it should bail if the user passes a keyword parameter we don't know about.

then i#ll just raise a Error by applying the kwargs to a function

Think this is worthwhile doing?

nicoddemus · 2017-02-08T21:49:23Z

doc/en/parametrize.rst

@@ -94,21 +94,37 @@ for example with the builtin ``mark.xfail``::
    @pytest.mark.parametrize("test_input,expected", [
        ("3+5", 8),
        ("2+4", 6),
-        pytest.mark.xfail(("6*9", 42)),
+        pytest.param("6*9", 42,


We should add more examples of pytest.param, including usages of the id parameter in isolation and used together with parametrize(..., id=).

Do you plan to tackle this @RonnyPfannschmidt?

I agree, FWIW.

nicoddemus · 2017-02-08T21:52:13Z

doc/en/parametrize.rst

+        ])
+        def test_eval(test_input, expected):
+            assert eval(test_input) == expected
+


Please complement this stating why this mechanism was replaced in favor of pytest.param (not being able to mark functions, strange syntax to newcomers). Also please state that this mechanism will start to emit warnings in 3.1 and will be dropped in 4.0.

Do you plan to tackle this @RonnyPfannschmidt?

Just noticed you did already, nevermind my previous comment

nicoddemus · 2017-02-08T22:01:26Z

_pytest/mark.py

 def alias(name):
    return property(attrgetter(name), doc='alias for ' + name)


+class ParameterSet(namedtuple('ParameterSet', 'values, marks, id')):


I think we should add unittests for ParameterSet to make sure we cover all corner cases and possible validation errors.

i added a few, perhaps we should make an issue about more detailed tests

nicoddemus · 2017-02-08T22:08:16Z

_pytest/mark.py

 def alias(name):
    return property(attrgetter(name), doc='alias for ' + name)


+class ParameterSet(namedtuple('ParameterSet', 'values, marks, id')):
+    @classmethod
+    def param(cls, *value, **kw):


Nitpick: should be *values

nicoddemus · 2017-02-08T22:08:21Z

_pytest/mark.py

+        return cls(value, marks, id)
+
+    @classmethod
+    def extract_from(cls, param, legacy_force_tuple=False):


I didn't quite get the legacy_force_tuple parameter here, even after looking at where it's used. Could add a quick-docstring explaining why it's needed?

will do, it may need a better name, its for the special case of single name parametrizations

nicoddemus · 2017-02-08T22:08:50Z

_pytest/mark.py

+        return cls(value, marks, id)
+
+    @classmethod
+    def extract_from(cls, param, legacy_force_tuple=False):


Nitpick: the param parameter should be value

extract_from operates on a legacy parameterset, so the name value is certainly wrong

nicoddemus · 2017-02-08T22:10:24Z

_pytest/mark.py

+
+
+    @property
+    def deprecated_arg_dict(self):


Please add a _ prefix

wont do that as its used in open code and just bad data

nicoddemus · 2017-02-08T22:17:29Z

testing/python/metafunc.py

+        reprec = testdir.inline_run()
+        passed, failed = (0, 2) if strict else (2, 0)
+        reprec.assertoutcome(passed=passed, failed=failed)
+


We should add a test for the situation where the user uses passes id to a param and to parametrize in the same call.

nicoddemus · 2017-03-15T15:24:09Z

_pytest/mark.py

+            assert isinstance(marks, (tuple, list, set))
+
+        id = kw.pop('id', None)
+        assert not kw, kw


Think this is worthwhile doing?

coveralls · 2017-03-15T15:25:51Z

Coverage increased (+0.01%) to 92.676% when pulling e4d268c on RonnyPfannschmidt:marked-value into 55b891d on pytest-dev:features.

coveralls · 2017-03-15T16:02:20Z

Coverage increased (+0.01%) to 92.669% when pulling 9803119 on RonnyPfannschmidt:marked-value into 5482dfe on pytest-dev:features.

nicoddemus · 2017-03-16T18:13:12Z

Guys, anybody else wants to take a look at this PR before merging? Unless somebody says otherwise, I will merge this tomorrow. 👍

The-Compiler · 2017-03-16T18:35:26Z

_pytest/mark.py

-    return {'mark': MarkGenerator()}
+    return {
+        'mark': MarkGenerator(),
+        'param': ParameterSet.param,


You might want to do this differently as we're getting rid of pytest_namespace in your other PR - or just deal with the conflicts and fix it up there, I guess.

well, i deal the conflicts i fold the conflicts ^^

The-Compiler · 2017-03-16T19:05:51Z

_pytest/mark.py

+            and may or may not be wrapped into a mess of mark objects
+
+        :param legacy_force_tuple:
+          enforce tuple wrapping so single arugment tuple values dont get decomposed and break tests


Some nitpicks:

arugment -> argument

dont -> don't

indent two spaces more for consistency

The-Compiler · 2017-03-16T19:10:07Z

doc/en/parametrize.rst

@@ -94,21 +94,37 @@ for example with the builtin ``mark.xfail``::
    @pytest.mark.parametrize("test_input,expected", [
        ("3+5", 8),
        ("2+4", 6),
-        pytest.mark.xfail(("6*9", 42)),
+        pytest.param("6*9", 42,


I agree, FWIW.

The-Compiler · 2017-03-16T19:11:00Z

doc/en/parametrize.rst

+
+  This was an initial hack to support the feature but soon was demonstrated to be incomplete,
+  broken for passing functions or applying multiple marks with the same name but different parameters.
+  The old syntax will be removed in `pytest 4.0`.


Why the backticks?

The-Compiler · 2017-03-16T19:11:18Z

doc/en/parametrize.rst

 Let's run this::

    $ pytest
    ======= test session starts ========
-    platform linux -- Python 3.5.2, pytest-3.0.7, py-1.4.32, pluggy-0.4.0
+    platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0


Update your pytest! 😉

The-Compiler · 2017-03-16T19:12:33Z

testing/python/metafunc.py

+        passed, failed = (0, 2) if strict else (2, 0)
+        reprec.assertoutcome(passed=passed, failed=failed)
+
+
    def test_pytest_make_parametrize_id(self, testdir):
        testdir.makeconftest("""
            def pytest_make_parametrize_id(config, val):


Do we still have tests testing the legacy syntax/compatibility?

The-Compiler · 2017-03-16T19:12:33Z

testing/python/metafunc.py

+        passed, failed = (0, 2) if strict else (2, 0)
+        reprec.assertoutcome(passed=passed, failed=failed)
+
+
    def test_pytest_make_parametrize_id(self, testdir):
        testdir.makeconftest("""
            def pytest_make_parametrize_id(config, val):


Do we still have tests testing the legacy syntax/compatibility?

coveralls · 2017-03-17T08:11:01Z

Coverage increased (+0.01%) to 92.67% when pulling b328c56 on RonnyPfannschmidt:marked-value into 5482dfe on pytest-dev:features.

coveralls · 2017-03-17T08:19:40Z

Coverage increased (+0.01%) to 92.67% when pulling 58d1529 on RonnyPfannschmidt:marked-value into 5482dfe on pytest-dev:features.

coveralls · 2017-03-17T08:28:44Z

Coverage increased (+0.01%) to 92.67% when pulling 58d1529 on RonnyPfannschmidt:marked-value into 5482dfe on pytest-dev:features.

RonnyPfannschmidt · 2017-03-17T12:53:27Z

i am thinking of folding a few commits, any opinion?

coveralls · 2017-03-17T13:06:06Z

Coverage increased (+0.01%) to 92.662% when pulling a9a8697 on RonnyPfannschmidt:marked-value into a122ae8 on pytest-dev:features.

nicoddemus · 2017-03-17T13:25:40Z

i am thinking of folding a few commits, any opinion?

Sure, go ahead!

this allows a clear addition of parameterization parameters that carry along marks instead of nesting multiple mark objects and destroying the possibility of creating function valued parameters, it just folders everything together into one object carrfying parameters, and the marks.

coveralls · 2017-03-17T16:32:28Z

Coverage increased (+0.01%) to 92.662% when pulling e368fb4 on RonnyPfannschmidt:marked-value into a122ae8 on pytest-dev:features.

The-Compiler · 2017-03-17T16:35:28Z

_pytest/python.py

+        parameters = [
+            ParameterSet.extract_from(x, legacy_force_tuple=force_tuple)
+            for x in argvalues]
+        del argvalues


What's the point of this?

i used this as refactoring aid, the argnames/argvalues variables where badly named and used
just killing it off the local namespace helped finding errors, and it also prevents using them after they shouldnt be used

The-Compiler · 2017-03-18T17:07:04Z

LGTM now, but still needs a changelog entry.

coveralls · 2017-03-20T09:33:17Z

Coverage increased (+0.01%) to 92.662% when pulling e8a1b36 on RonnyPfannschmidt:marked-value into a122ae8 on pytest-dev:features.

flub reviewed Sep 19, 2016

View reviewed changes

RonnyPfannschmidt force-pushed the marked-value branch from 431bd2b to fece1fc Compare October 24, 2016 11:55

RonnyPfannschmidt changed the title ~~[wip] introduce pytest.Marked as holder for marked parameter values~~ introduce pytest.Marked as holder for marked parameter values Oct 24, 2016

RonnyPfannschmidt force-pushed the marked-value branch from a8570cb to 5fe5acf Compare January 19, 2017 09:28

nicoddemus requested changes Feb 8, 2017

View reviewed changes

nicoddemus approved these changes Mar 15, 2017

View reviewed changes

RonnyPfannschmidt force-pushed the marked-value branch from e4d268c to 9803119 Compare March 15, 2017 15:44

The-Compiler requested changes Mar 16, 2017

View reviewed changes

RonnyPfannschmidt force-pushed the marked-value branch from 58d1529 to a9a8697 Compare March 17, 2017 12:50

RonnyPfannschmidt force-pushed the marked-value branch from a9a8697 to e368fb4 Compare March 17, 2017 15:55

The-Compiler reviewed Mar 17, 2017

View reviewed changes

The-Compiler approved these changes Mar 18, 2017

View reviewed changes

add changelog

e8a1b36

The-Compiler merged commit de8607d into pytest-dev:features Mar 20, 2017

RonnyPfannschmidt mentioned this pull request May 13, 2017

deprecate unpacking marks in parameter values and provide a clean alternative #1748

Closed

The-Compiler mentioned this pull request May 23, 2017

Emit warnings for legacy parametrization + marking #2427

Closed

RonnyPfannschmidt deleted the marked-value branch June 11, 2017 13:46

mgeier mentioned this pull request Oct 9, 2018

broken? mgeier/pytest-auto-parametrize#1

Closed

introduce pytest.Marked as holder for marked parameter values #1921

introduce pytest.Marked as holder for marked parameter values #1921

Conversation

RonnyPfannschmidt commented Sep 7, 2016

coveralls commented Sep 7, 2016

coveralls commented Sep 7, 2016

coveralls commented Sep 7, 2016

flub left a comment

Choose a reason for hiding this comment

RonnyPfannschmidt commented Sep 19, 2016

flub commented Sep 19, 2016

RonnyPfannschmidt commented Sep 19, 2016

flub commented Sep 19, 2016

The-Compiler commented Sep 19, 2016

RonnyPfannschmidt commented Sep 19, 2016

RonnyPfannschmidt commented Sep 19, 2016

flub commented Sep 21, 2016

The-Compiler commented Sep 21, 2016 • edited Loading

RonnyPfannschmidt commented Sep 24, 2016

flub commented Sep 24, 2016

RonnyPfannschmidt commented Sep 24, 2016

nicoddemus commented Nov 9, 2016

The-Compiler commented Nov 9, 2016

RonnyPfannschmidt commented Nov 9, 2016

nicoddemus commented Nov 9, 2016 • edited Loading

nicoddemus commented Nov 9, 2016

hpk42 commented Nov 9, 2016

The-Compiler commented Nov 9, 2016

RonnyPfannschmidt commented Nov 9, 2016

hpk42 commented Nov 9, 2016

coveralls commented Jan 19, 2017

RonnyPfannschmidt commented Jan 19, 2017

nicoddemus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Mar 15, 2017

coveralls commented Mar 15, 2017

nicoddemus commented Mar 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Mar 17, 2017

coveralls commented Mar 17, 2017

The-Compiler commented Sep 21, 2016 •

edited

Loading

nicoddemus commented Nov 9, 2016 •

edited

Loading