behave with cocotb verification framework for hardware verification.

[jahagirdar]

I am interested in doing BDD for ASIC and FPGA verification using the cocotb verification framework .I have spent a weekend putting together a quick and dirty feature file to cocotb test file converter.

If possible I would like to contribute a patch to behave for supporting cocotb based verification. I had a few questions:

• Is it possible to dump the complete behave testcase for a scenario as a pythonfile instead of running the test? I would like to study the logic implemented by behave for different usecases.
• A single scenario can run for anywhere from a few minutes to a few days. Hence running scenario's in parallel is important. I see there is already another discussion on this topic. What does the roadmap for parallel execution look like?
• Cocotb uses async/await to transfer control between various parts of the python testcode and the simulator. Does behave support this?

[jenisys]

P1. Dump test scenario as Python code

• The short answer is no.
• The long answer is: Why would you want to do this?
  The result would be a sequence of function calls with parameters of the step-implementation functions (and the calls to the before/after hooks in between).

P2. Parallel runner: There is currently no schedule for this feature, Use one of the existing ones, provide your own parallel test runner or wait until one is provided (whatever suites you best). A test runner is a extension point in behave. Therefore, it is „simple“ to provide your own (and use it).

P3. behave supports async steps that run in a coroutine. That should simplify the use in your specific case. But the coroutine execution should normally be completed at the end of a scenario.

NOTES:

• behave provides a generic functionality that can be used for any testing domain
• Currently, you seem to have an idea what you want to do. But you do not have a working prototype (at least it sounds like that). Therefore, it is not clear that behave needs to be patched at all.
• You should first think how you want to describe your tests as scenarios in Gherkin and provide the sketch of a step library for your testing domain. If the result of this sketch/prototype looks promising to you, you should continue.

SEE ALSO:

• docs: Runner Operations (Pseudo code for: Scenario) — related-to: P1
• features/step.async_steps.feature — related-to: P3