+28
−0
+32
−0
+31
−0
Loading
getPermittedComponents(): the prose says that all component instances are returned when the starting behaviour is not specified. The bodies returned the empty set instead, and took the targets of any first interaction, tester-input event or not. With that, the two constraints about how a block starts stayed silent on a block that starts wrongly, while the participation constraints reported testers against a starting event that does not exist. The bodies of MultipleCombinedBehaviour and ExceptionalBehaviour now return all components unless the block starts with a tester-input event, and only such an event counts. OptionalBehaviour gets the operation the prose already names: the source and the targets of its starting interaction. OptionalBehaviour also gets getParticipatingComponents(): seen from its container, an optional participates through the source of its starting interaction only. The participation restrictions exist so that no behaviour is defined for a tester that cannot know whether to execute it; the target of an optional is triggered explicitly, so it takes no part in the enclosing scope. A nested optional's target is therefore permitted inside that optional and nowhere else, and its source has to be permitted in the containing one. OptionalBehaviourParticipation is reduced to the two operations. The earlier text carried the permitted components inline, cast the first behaviour to an interaction without checking, and used select where collect was meant, so it could not be evaluated at all once an optional was nested. Six fixtures cover what the suite did not reach: a block without a tester-input start in an alternative and in a guarded default, a default that starts with a tester-to-SUT send, and nested optionals with a permitted target, a source that is not permitted, and a target used outside. The constraint text is taken from the specification document; a fresh export differs from the file only in the two intended error(...) wrappers.