Skip to content

Fixes #276: configure and unconfigure Feature class #282

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

Conversation

sliwinski-milosz
Copy link
Contributor

To be able to unconfigure Feature class during test execution we need to access previous config. I added ConfigStack for that.

I used that stack also to avoid accessing deprecated pytest.config while getting config.hook.pytest_bdd_apply_tag.

I also think that def scenarios(*feature_paths, **kwargs): needs refactor.

… tests separation. Do not use deprecated pytest.config global variable
@coveralls
Copy link

coveralls commented Dec 8, 2018

Coverage Status

Coverage increased (+0.04%) to 93.49% when pulling c3088b2 on sliwinski-milosz:add_configure_and_unconfigure_to_Features into fb44fc3 on pytest-dev:master.

@sliwinski-milosz
Copy link
Contributor Author

Can we firstly merge this pull requests as it fixes CI tests? Please review :)

@@ -47,14 +49,19 @@ def add_bdd_ini(parser):
@pytest.mark.trylast
def pytest_configure(config):
"""Configure all subplugins."""
ConfigStack.add(config)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need a stack at all? Shouldn't the hook only be called once?

Copy link
Contributor Author

@sliwinski-milosz sliwinski-milosz Jan 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is all here to fix tests that we run using testdir plugin.

Our problem is that:

  1. When we start all tests it calls pytest_configure.
  2. Then when it starts some test with testdir it calls pytest_configure again with new config.
  3. After test (as in current code there is no pytest_unconfigure) it just runs another test.
  4. As pytest_configure from point 2 changed pytest config - our tests start to fail as they expect default config (from point 1).

I added pytest_unconfigure hook so now after running test using testdir it can bring back previously used config.

So this pull request changes logic to:

  1. When we start all tests it calls pytest_configure (we store config on stack).
  2. Then when it starts some test with testdir it calls pytest_configure again with new config (again we store new config on stack).
  3. After tests it calls pytest_unconfigure -> we bring back previous config from the stack.
  4. We have previous config back and tests pass :)

Please note that it has been discussed also here pytest-dev/pytest#4495

def get_previous(cls):
cls._stack.pop()
if cls._stack:
return cls._stack[-1]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should probably be an explicit return None here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added


@classmethod
def get_pytest_bdd_apply_tag_hook(cls):
return cls._stack[-1].hook.pytest_bdd_apply_tag
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be cleaner to make this method call the hook directly (by taking *args/**kwargs).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Done

In tests use -m instead of -k for running tests by marker expressions
@sliwinski-milosz
Copy link
Contributor Author

Merged #287

@sliwinski-milosz
Copy link
Contributor Author

This pull request fixes CI tests

@The-Compiler
Copy link
Member

Would be great if someone else could take a look at this as well - I'm quite busy with exams coming up, so I don't trust my brain enough to review bigger things right now 😉

@youtux youtux self-requested a review January 15, 2019 21:29
Copy link
Contributor

@youtux youtux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry if it took me so long to review this case, @sliwinski-milosz

@@ -110,3 +110,23 @@ def get_markers_args_using_iter_markers(node, mark_name):
def get_markers_args_using_get_marker(node, mark_name):
"""Deprecated on pytest>=3.6"""
return getattr(node.get_marker(mark_name), 'args', ())


class ConfigStack(object):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to define an object to handle a stack? I'd rather use just a list and name it config_stack

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to list

cls._stack.append(config)

@classmethod
def get_previous(cls):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also because get_previous should not have side effects, but instead it removes the current element and return the previous one

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed

@@ -250,6 +250,8 @@ def __bool__(self):
class Feature(object):

"""Feature."""
strict_gherkin = None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that the Feature class should contain configuration options like strict_gherkin or base_dir. Instead, callers of Feature(...) should consult the current config from the stack.

@sliwinski-milosz
Copy link
Contributor Author

Closing in favour of:
#288

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants