A limitation of our rules format is that today we can easily say the test target needs to meet A, and, B and C by adding an expectation for A, B and C. Where we have some requirement where the test target needs to meet A, or B, or C, things get a little more complicated, and we end up either with a fairly complicated expectation that needs a "at least one of the following is true', or we need to create a composite rule.
The "at least one" approach works for very simple cases, but it can get pretty complicated. Composite rules work too, however for some of those I've found that they can make things more difficult to understand than they need. Composite rules also have a good deal of overhead unfortunately, which doesn't seem idea.
One way we could potentially solve this is to allow alternatives to an expectation, as kind of "or" conditions. That could look something like this. We could also then require that this not have more than one expectation, to manage complexity a bit more.
## Applicability
This rule applies to any ...
## Expectation
Each test target ...
### Alternative
The test target ...
One composite rule that I very much think this should be used for is on keyboard trap. Having the standard key and non-standard key expectations in different rules doesn't help reuse or comprehension. That's certainly not true for all composite rules, but this one sticks out to me as sub-optimal.
A limitation of our rules format is that today we can easily say the test target needs to meet A, and, B and C by adding an expectation for A, B and C. Where we have some requirement where the test target needs to meet A, or B, or C, things get a little more complicated, and we end up either with a fairly complicated expectation that needs a "at least one of the following is true', or we need to create a composite rule.
The "at least one" approach works for very simple cases, but it can get pretty complicated. Composite rules work too, however for some of those I've found that they can make things more difficult to understand than they need. Composite rules also have a good deal of overhead unfortunately, which doesn't seem idea.
One way we could potentially solve this is to allow alternatives to an expectation, as kind of "or" conditions. That could look something like this. We could also then require that this not have more than one expectation, to manage complexity a bit more.
One composite rule that I very much think this should be used for is on keyboard trap. Having the standard key and non-standard key expectations in different rules doesn't help reuse or comprehension. That's certainly not true for all composite rules, but this one sticks out to me as sub-optimal.