Having dived a bit deeper, I'm concluding that there are some design decisions which need to be made here.
For a normal scenario like:
Feature: my feature
Scenario: my scenario
Given step 1
When step 2
Then step 3
The hierarchy is:
Feature: my feature
- Scenario: my scenario
- Step: Given step 1
- Step: Given step 2
- Step: Given step 3
As currently designed, for reporting purposes a Step is mapeped to wdio's "test-case", and a Scenario is mapped to wdio's "suite".
However, for a scenario outline like:
Feature: my feature
Scenario Outline: my scenario outline
Given step 1 for <thing>
When step 2
Then step 3
Examples: Big things
| thing |
| Elephant |
| Whale |
Examples: Small things
| thing |
| Mouse |
| Bacterium |
the hierarchy is:
Feature: my feature
- Scenario Outline: my scenario outline
- Examples table 1: Big things
- Example row 1: thing=Elephant
- Step: Given step 1 for Elephant
- Step: When step 2
- Step: Then step 3
- Example row 2: thing=Whale
- Step: Given step 1 for Whale
- Step: When step 2
- Step: Then step 3
- Examples table 2: Small things
- Example row 1: thing=Mouse
- Step: Given step 1 for Mouse
- Step: When step 2
- Step: Then step 3
- Example row 2: thing=Bacterium
- Step: Given step 1 for Bacterium
- Step: When step 2
- Step: Then step 3
So wdio's "test-case" should still map to a Step, but then we are faced with a problem - we need to fit a three-level heirarchy into wdio's concept of "suite".
The easiest path seems to be that each Example Row be mapped to a wdio "suite", so that reporting can still function. So a suite would be named something like "my scenario outline, examples 1 (Big things), row 1".
I actually have this working in the local copy of my fork, but there are quite a few implicit design decisions I'm steamrolling through. How do the maintainers usually make design decisions like this? Should there be a discussion elsewhere?