Skip to content

Expected failures #2

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

Open
jayvdb opened this issue Jan 10, 2020 · 6 comments
Open

Expected failures #2

jayvdb opened this issue Jan 10, 2020 · 6 comments

Comments

@jayvdb
Copy link

jayvdb commented Jan 10, 2020

There doesnt appear to be a way to declare that some units will be expected failures.

@jayvdb
Copy link
Author

jayvdb commented Jan 12, 2020

It looks like it is possible to define an entire class as expected failures

@expand
class TestFailedStdlibNames(unittest.TestCase):

    @foreach(list_of_expected_failures)
    @unittest.expectedFailure
    def test_package(self, name):
        self._do_test(name)

It should therefore be possible to create a derivative of unittest.expectedFailure which checks a subset to determine if the unit is an expected failure.

@zuo
Copy link
Owner

zuo commented Mar 12, 2020

Thanks for your feedback. I'll keep an eye on this issue. :-)

(I am going to make a new release, though probably not very soon...)

@zuo
Copy link
Owner

zuo commented Oct 10, 2021

Hello.

@jayvdb Big thanks for you contribution!

I apologise for such a long inactivity -- for personal reasons I was unable to actively maintain the project, but now that will change. I hope I'll be able to answer to your ideas in the coming weeks.

Best regards!

@zuo
Copy link
Owner

zuo commented Nov 13, 2021

@jayvdb I am not sure whether I understand correctly what is specified by items of list_of_expected_failures in the example provided by you.

Generally, I see two possible improvements here:

  • ability to apply @unittest... decorators, such as expectedFailure, to test methods decorated with @foreach(...) -- making a decorator (such as expectedFailure) be applied to all cases generated from the given test method definition;

  • ability to apply such a decorator selectively, i.e., only to cases corresponding to some (selected) items of a parameter collection passed to @foreach(...).

Did you refer to one of these two ideas?

@jayvdb
Copy link
Author

jayvdb commented Nov 13, 2021

I was thinking of the second case, selectively indicating that a few of the cases will fail.
i.e. generate cases for ['a', 'b', 'c', ...], and indicate that ['c', 'z'] are expected failures, and should handled by expectedFailure decorator, causing a failure if they succeed.

@zuo
Copy link
Owner

zuo commented Nov 15, 2021

In some later version (not in the 0.4.0 that is supposed to be released soon), I plan to add a possibility to specify -- per param instance -- a decorator (or multiple decorators) to be applied to the method parametrized using that param instance.

It would be specified in a similar way contexts are... Something along the lines of the following:

class TestFoo(...):
    @foreach(
        param(...),
        param(...).deco(unittest.expectedFailure),
        param(...)
            .deco(my_custom_decorator),
            .deco(unittest.skipIf(...)),
    )
    def test(...):
        ...

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

2 participants