search

spyoungtech / behave-webdriver

Selenium webdriver step library for use with the behave BDD testing framework
MIT License
62 stars 21 forks source link

behave-webdriver #82

Open gaganhattar opened 4 years ago

gaganhattar commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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.