Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Scopes "module" or "class" circumvent the blocking #45

Closed
ymyke opened this issue Aug 16, 2020 · 4 comments · Fixed by #61
Closed

Scopes "module" or "class" circumvent the blocking #45

ymyke opened this issue Aug 16, 2020 · 4 comments · Fixed by #61
Labels
documentation Improvements or additions to documentation

Comments

@ymyke
Copy link

ymyke commented Aug 16, 2020

Thanks for the great plugin!

I noticed the following:

Example 1:

import requests

def test():
    requests.get("http://httpbin.org/status/200")

This will raise SocketBlockedError, as expected.

Example 2:

import pytest
import requests

@pytest.fixture # scope == "function" by default
def getit():
    requests.get("http://httpbin.org/status/200")

def test(getit):
    pass

This will also raise the SocketBlockedError. Also as expected.

Example 3:

import pytest
import requests

@pytest.fixture(scope="module") # <== Notice the different scope!
def getit():
    requests.get("http://httpbin.org/status/200")

def test(getit):
    pass

This will pass. No exception.

To me, this was unexpected and lead to some debugging headaches.

Is this intended behavior or a bug? Is there a way to make the plugin also prevent cases such as this one?

@ymyke ymyke changed the title scopes module or class circumvent the blocking scopes "module" or "class" circumvent the blocking Aug 16, 2020
@ymyke ymyke changed the title scopes "module" or "class" circumvent the blocking Scopes "module" or "class" circumvent the blocking Aug 16, 2020
@ymyke
Copy link
Author

ymyke commented Aug 17, 2020

Looking into the pytest socket code and the pytest documentation, this seems to be expected behavior:

  • socket_disabled is a normal fixture, i.e. with "function" scope.
  • Fixture resolution order states that higher order fixtures are resolved before lower order ones.

Hence, in example 3 above the get call will happen before the socket_disabled fixture.

Maybe worth mentioning this in the documentation.

@miketheman
Copy link
Owner

Hi @ymyke !
Thanks for the diagnosis, and report.

Where in the documentation would you have expected to find this kind of specific behavior definition?

@miketheman miketheman added the documentation Improvements or additions to documentation label Feb 7, 2021
@ymyke
Copy link
Author

ymyke commented Feb 8, 2021

Maybe in a separate section called "Caveats" or "Gotchas"? Or in an FAQ section? Maybe with a title such as "Network access in some of my fixtures work despite disabling sockets, why?".

miketheman added a commit that referenced this issue Mar 30, 2021
Resolves #45

Signed-off-by: Mike Fiedler <miketheman@gmail.com>
@miketheman
Copy link
Owner

@ymyke Please check out #61 and let me know what you think!

miketheman added a commit that referenced this issue Mar 30, 2021
Resolves #45

Signed-off-by: Mike Fiedler <miketheman@gmail.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants