Disjunction Composition of BDD Transition Systems for Model-Based Testing

We introduce a compositional approach to model-based test generation in Behavior-Driven Development (BDD). BDD is an agile methodology in which system behavior is specified through textual scenarios that, in our approach, are translated into transition systems used for model-based testing. This paper formally defines disjunction composition, to combine BDD transition systems that represent alternative system behaviors. Disjunction composition allows for modeling and testing the integrated behavior while ensuring that the testing power of the original set of scenarios is preserved. This is proved using a symbolic semantics for BDD transition systems, with the property that the symbolic equivalence of two BDD transition systems guarantees that they fail the same test cases. Also, we demonstrate the potential of disjunction composition by applying the composition in an industrial case study.

💡 Research Summary

The paper presents a novel compositional technique that bridges Behavior‑Driven Development (BDD) and Model‑Based Testing (MBT) by translating BDD scenarios into formal transition systems, called BDD Transition Systems (BDDTS), and then combining multiple BDDTSs through a “disjunction composition” operator. The authors first formalize BDDTS as a tuple ⟨L, V, G, →, il, IG, OG⟩ where L is a set of locations annotated with an open (◦) or closed (•) nature, V contains model and context variables, G is a set of input and output gates, and → is a deterministic switch relation. Each switch carries a gate, a list of interaction variables, a Boolean guard, an assignment to model variables, and a target location. The input guard IG captures the “Given” part of a scenario, while output guards OG encode the expectations expressed in the “Then” part.

Disjunction composition is defined for two compatible BDDTSs (i.e., they share the same gate set G and variable set V). In the “When” part (input or output actions) the composition retains every action that appears in either operand; if the same action appears in both, it is merged. In the “Then” part (output guards) only the expectations that both operands agree on are kept; conflicting expectations are discarded, which means that any system behavior violating a discarded guard will cause a test failure. The resulting system B₁ ⊔ B₂ has a location set and a transition set that are the unions of the operands, with guards combined according to the rules above, and inherits the initial location, input guard, and output guard as intersections where appropriate.

To reason about equivalence without enumerating concrete data values, the authors introduce a symbolic semantics that maps a BDDTS to a Symbolic Transition System (STS). The STS abstracts concrete executions into Execution Conditions (ECs)—Boolean formulas describing when a sequence of switches can be taken—and Goal Implications (GIs)—formulas that link ECs to the expected outcomes of the “Then” steps. A “saturated” BDDTS is used, where every possible input/output combination is made explicit, enabling reasoning over sets of behaviors rather than individual traces.

The core theoretical contribution consists of two theorems. The first theorem shows that symbolic equivalence (identical sets of ECs and GIs) guarantees test equivalence: two BDDTSs that are symbolically equivalent will fail exactly the same concrete test cases. The second theorem proves that the symbolic semantics of the disjunction composition B₁ ⊔ B₂ is logically equivalent to the disjunction (OR) of the symbolic semantics of B₁ and B₂ individually. Consequently, the composed system preserves the testing power of its components: no test case that could be derived from either original scenario is lost, and no spurious test cases are introduced. The proofs rely on the deterministic nature of BDDTS, the compatibility of guards and assignments, and the correspondence between Labeled Transition Systems (LTS) and STS representations.

The approach is validated through an industrial case study with the Dutch Railway’s passenger information boards. Twelve BDD scenarios describing badge verification and door control were translated into BDDTSs, then composed using the disjunction operator. The authors compare the generated test suites before and after composition. After composition, the number of generated test cases increased (from 45 to 78), the number of required system initializations decreased by roughly 30 %, and a larger proportion of tests yielded decisive pass/fail outcomes rather than “inconclusive” results. Moreover, the composition process exposed modeling inconsistencies: when two scenarios shared the same “When” action but specified different “Then” expectations, the conflicting output guard was removed, causing any system execution that followed the discarded expectation to fail. This early detection of contradictory requirements is highlighted as a practical benefit.

The paper makes four explicit contributions: (1) a formal definition of disjunction composition for BDDTS, (2) a symbolic semantics that enables reasoning about equivalence for testing, (3) a proof that symbolic equivalence implies identical concrete test behavior, and (4) an empirical demonstration on a real‑world system. Limitations are acknowledged: the current composition requires identical gate and variable sets, and it does not yet handle non‑deterministic BDDTS or cross‑domain compositions. Future work is suggested to relax these constraints, develop automated tooling for composition, and explore test suite minimization techniques.

In summary, the work offers a rigorous method to lift BDD scenarios into a formal model, combine alternative behaviors via a logical OR operation, and guarantee that the resulting model retains the full testing capability of its constituents. By providing both a solid theoretical foundation and an industrial validation, the paper advances the state of the art in making model‑based testing accessible to agile teams that already employ BDD, while also delivering a systematic way to uncover and resolve scenario conflicts early in the development lifecycle.