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

behave-webdriver #82

Open
gaganhattar opened this issue Sep 1, 2020 · 2 comments
Open

behave-webdriver #82

gaganhattar opened this issue Sep 1, 2020 · 2 comments

Comments

@gaganhattar
Copy link

gaganhattar commented Sep 1, 2020

Hi, I am writing Behave based framework. I wish to know what happens under the hood such that feature file can re-use step files and can able to call behave-webdriver steps without any implementation as mentioned in https://behave-webdriver.readthedocs.io/en/stable/quickstart.html#importing-the-step-implementations

How can we import steps in feature file in Behave.

@spyoungtech
Copy link
Owner

Hi Gagan,

One of the key pieces to understanding how to re-use step definitions is understanding the step registry. The decorators provided by behave (@step, @given, @when, @then) will insert the function definition into a registry according to its step text and matcher.

When following the use of Behave as documented, the decorators are applied at import time. I.E. when the decorators themselves execute. Unfortunately, because of this design in Behave, library authors lose a lot of potential for flexibility or re-usability for users of step definitions/libraries.

The way that behave-webdriver manages to get a degree of flexibility is by implementing the vast majority of its functionality into a single class that is expected to be present in the behave context. You’ll notice that most of the actual step functions are very short — usually just calling one method of the class in the context.

So, users can subclass the class(es) provided by behave-webdriver and provide their own implementations for various functionality. In short, the key is moving most of the functionality out of the decorated step functions and in to a class that is expected to be provided by the user to the context.

I want to mention that I also author another project called behave-classy which allows you to implement step definitions as classes, rather than functions. This allows users to subclass and modify step definitions before they are even put into the global registry. The code there deals closely with the builtin behave step registry and decouples step definitions from that registry at import time; so step definitions (as classes) can be imported and subclasses without affecting the global registry, among other benefits.

I hope that helps you. Feel free to ask more questions if you have them @gaganhattar

@gaganhattar
Copy link
Author

gaganhattar commented Sep 1, 2020 via email

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

No branches or pull requests

2 participants