def before_scenario(context, scenario): """ Hanlder before the test scenario is run """ logging.info("Starting Scenario: %s", scenario.name) if scenario.name == 'Test PGaaS Product': use_fixture(provision_product, context) @capture def before_step(context, step): """ Handler before the test step is run """ logging.info("Starting Step: %s", step.name) if step.name == 'Create a clone of the cluster': use_fixture(provision_clone, context)
for row in context.example: print(row)
behave @listfile.txtwhich reads the list of feature files of FileLocations from the textual file „listfile.txt“. But if you want to run all examples of a ScenarioOutline or the complete ScenarioOutline, why do you not use tags ? Your initial question was that you want to run one Example row in a ScenarioOutline.
behavefor system tests or integration tests (not for ATDD or BDD) ?!?
I'm think about extentions. Like pytest has with
pluggy. Many projects has insane envrionment files.
@jenisys, what we think about implement a plugin manager for hooks?
I try explain my idea on this project https://github.com/dunossauro/hook_plug.
Something like install plugins in hooks and inside de plugins you can implamente modules and then put context variables and execute routines in hooks
@ErwinBeen There is a "Visual Testing" section in the Practical Tips on Testing chapter of the documentation. This is not a direct answer to your question, but at least you can find some information there that may help you to dig further.
Extending the docs, once you find something directly useful, is always welcome!
Regarding expansive Setup: Splitup the Setup in two Parts, First Part injects the Context attribute (via fixture and fixture-tag in before_feature or before_all hook), second part performs the setup when the Context attribute is actually used via Lazy-init (via a function call or property or ...). Therefore, you pay only for the setup if it is actually used by a step implementation or Python code. Problem: Other parts (Scenarios, Steps, Fixtures, ...) may partly destroy/modify your setup after it was performed and it may be hard to detect this case.
Linked example has a flaw: The step implementation should not always power-up the board but just ensure that the board is in powered-up state.