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

staticmethod tests fail when declared in a superclass #3466

Closed
radzak opened this issue May 12, 2018 · 4 comments
Closed

staticmethod tests fail when declared in a superclass #3466

radzak opened this issue May 12, 2018 · 4 comments
Labels
type: question general question, might be closed after 2 weeks of inactivity

Comments

@radzak
Copy link

radzak commented May 12, 2018

staticmethod test fails if you declare it in a superclass:

@pytest.fixture
def fixture():
    return True

class TestFoo:
    @staticmethod
    def test_me(fixture):
        assert fixture

class TestBar(TestFoo):
    ...

TestBar.test_me fails due to the TypeError: test_me() missing 1 required positional argument: 'fixture'.

TestFoo.test_me passes correctly.

@pytestbot
Copy link
Contributor

GitMate.io thinks possibly related issues are #747 (flakes test fail), #2528 (staticmethod functions are not collected for testing), #701 (py.test.exe - failed to create process), #2699 (staticmethod tests don't work with fixtures), and #1845 (Some tests fail on FreeBSD).

@Drew-Ack
Copy link

It would be really nice to see what you are trying to accomplish in your TestBar class.

I was able to implement working code this way.

conftest.py

All fixtures go here.

import pytest
@pytest.fixture
def fixture():
    return True

test_static.py

class TestFoo(object):                                         
    @staticmethod                                              
    def test_me(fixture):                                      
        print("running TestFoo's test_me")                     
        assert fixture                                         
                                                               
class TestBar(TestFoo):                                                                                         
    def test_me_through_TestFoo(self, fixture):                
        TestFoo.test_me(fixture)                                                              
    def test_me_trough_TestBar(self, fixture):                 
        TestBar.test_me(fixture)                               

Results

TestFoo.test_me .
TestBar.test_me F
TestBar.test_me_through_TestFoo .
TestBar.test_me_through_TestBar .

It seems to be an inheritance issue.
When TestBar inherits TestFoo's methods, it fires off the test_me. I assume it has an issue with the signature. Ill need someone with more experience to chime in with why this is.

A possible fix

Change it from a static method to a class method.

class TestFoo(object):                           
    @classmethod                                 
    def test_me(cls, fixture):                   
        print("running TestFoo's test_me")       
        assert fixture        

TestFoo wont be able to run test_me as a test itself, but classes that inherit from TestFoo will run properly.

Results

TestFoo.test_me_through_TestFoo    .
TestFoo.test_me_through_TestBard   .

Some Resources

A little light reading on class method and static methods among a few other things.

@nicoddemus nicoddemus added the type: question general question, might be closed after 2 weeks of inactivity label May 15, 2018
@nicoddemus
Copy link
Member

Thanks @Drew-Ack for providing a working solution! @radzak is the solution good enough as a workaround?

@nicoddemus
Copy link
Member

After all the recent trouble we got from wrapping test functions to issue warnings when they get called directly (#3661, #3781), I wonder if it is wise for us to support this at all.

What do you think @RonnyPfannschmidt?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: question general question, might be closed after 2 weeks of inactivity
Projects
None yet
Development

No branches or pull requests

4 participants