-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
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 ( 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 So, users can subclass the class(es) provided by I want to mention that I also author another project called I hope that helps you. Feel free to ask more questions if you have them @gaganhattar |
Hi Spencer,Do you have example for "re-use step definitions using step registry"?
Thanks,Gagan
On Monday, 31 August 2020, 10:24:29 pm PDT, Spencer Phillip Young <[email protected]> wrote:
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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
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.
The text was updated successfully, but these errors were encountered: