---
title: "Overview of Rule-Based Test Generation"
slug: "overview-of-rule-based-test-generation"
description: "In this documentation article, learn all about rule-based test generation in Test Modeller."
tags: ["Test Case Generation", "Get Started", "Test Modeller"]
updated: 2024-09-27T15:01:04Z
published: 2024-09-27T15:01:04Z
canonical: "knowledge.curiositysoftware.ie/overview-of-rule-based-test-generation"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.curiositysoftware.ie/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview of Rule-Based Test Generation

In this documentation article, learn all about rule-based test generation in Quality Modeller.

[Embedded content](https://www.youtube.com/embed/DH36yApLjPY?&amp;wmode=opaque&amp;rel=0)

Rules allow you to force the[**path generator**](/docs/how-to-generate-test-cases) down paths that contain particular data[**values**](/docs/generating-test-data-from-models) (outputs), while excluding others. They thereby provide a way to filter Test Cases when generating a test suite.

---

## Why use rules

Rules allow you to overlay constraints onto the Model, quickly generating different combinations of paths. This provides a fast alternative when modelling out the full logic for each set of scenarios would be cumbersome.

With rules and[**coverage profiles,**](/docs/test-case-coverage-explained) Quality Modeller can generate accurate tests for complex systems. Yet, the flowcharts their simplicity and usability. This is because rules provide a compact alternative to modelling out the full business logic as flowcharts.

---

## Key concepts

Rules leverage [**coverage profiles**](/docs/test-case-coverage-explained) to generate paths that include certain nodes. These blocks have rules assigned to them, containing particular values. Path generation using rules then generates paths that pass-through nodes that contain particular values in their rules. This overrides any nodes[**test data value**](/docs/generating-test-data-from-models) assigned to that block.

To filter based on these values, a variable is set at the model-level. This model-level Variables is then included in the rules and associated Coverage Profile. This variable creates a filter, allowing you to filter by test data values contained in the model rules. The filter uses Boolean logic. Paths that contain the specified values in their rules will then be included or excluded from the paths generated using that coverage profile.

There are therefore two types of variables involved in Quality Modeller. Each serves a different purpose:

1. **A "model-level variable"**used in rules and coverage profiles. This rule filters path generation based on values assigned to certain nodes/blocks.
2. **"Test data variables"** used to assign values to blocks at the model. These variables are used to define the outputs (values) of decision gates in the model. The values reflect the different logical journeys that a user or data can pass through a system.

You should keep these two types of variables separate in your understanding and practice. Do not use a variable to assign test data values to blocks at the model level and also to filter paths during generation. This risks creating ambiguity in the Boolean logic used to filter paths based on test data values.

It is best practice to name the model-level variable intuitively, for instance, naming it "Path type". This makes it clear that it is not a variable used to assign test data outputs to blocks, but rather that is used to filter based on test data outputs.

---

## Process Overview

The process for rule-based test generation is as follows for an individual model:

1. Identify relevant decision gates in your model. A 'relevant decision gate' is one with which you want to filter paths based on its outputs.
2. Create a model-level variable with which to filter paths.
3. Create rules for every node (output) in the relevant decision gate. The rule informs the path generator when it should include paths that pass through the node, based on data [**Values**](/docs/generating-test-data-from-models)set in the rule. The rule use the variable created in step 2.
4. Create a [**coverage profile**](/docs/test-case-coverage-explained) to filter paths based on the test data values. This Coverage Profile will generate paths that pass-through blocks with certain values contained in their rule. It uses the model-level variable created in step 2.
5. Generate test cases from the model. This will force the test generation engine down the paths with values included by the rules and coverage profile.T

The true value of using rules is realised when [**Subflows**](/docs/subprocesses-explained) are used. This enables accurate integrated test and data generation. You can link Subflows in Master Models, generating paths that take certain end-to-end routes through the modelled logic. This requires the following additional steps:

1. Embed a Subflow for which rules have been defined in aMaster Model.
2. Create a model-level variable in the master flow. This calls particular test data variables in the Subflows, filtering paths based on the values assigned in rules at the subflow level.
3. Create a coverage profile that will filter paths based on the values associated with the test data variables specified in #6.

The links in the above list provide complete articles on creating test data variables, tagging values and generating tests. The following two articles focus on using test data variables to inform rules.

They provide instructions on creating rules and coverage profiles for rule-based generation. The [**first article**](/docs/rule-based-test-generation-for-an-individual-model) sets out how to use rules within an individual model (steps 1-5 above). [**The second**](/docs/rule-based-test-generation-with-subflows)provides instructions on uses rules with Subflows (steps 6-8).

Quality Modeller is Curiosity's flow-driven model-based tool which provides a range of accelerators and connectors for building flowcharts rapidly. Align all stakeholders to quality outcomes and create critical assets early, delivering superior software at speed.

Test cases are equivalent to paths through the model of a system under test. They are generated automatically from a model, with or without test data and test automation associated with them. Test Modeller has coverage techniques using advanced algorithms to generate the smallest set of test cases needed to test given features with a required level of rigour.

A Model is a canvas and the Flow that is built onto it. There are several types of Model, some of which display different tabs and tools on the toolbar in Quality Modeller.

Test Data Variables are sets of data that can be attached to blocks in models. This data can be custom, synthetic, automated etc. Variables are basically assigned data values and rules to blocks, and this data is used when automation is run.

Coverage Profiles are a wrapper for Coverage settings and options. Any number of Coverage Profiles can be created as required, each with its own Coverage settings. The Coverage button is on the Test Generation tab of a Model. Quality Modeller Models come with Default Profile, User Stories and Test Cases Profiles built in.

Subflows are used to quickly embed and re-use models within a master model. Subflows hide detailed or complex modelling and make the master Flow more readable. They enable scalability by building out the complexity from smaller, more step-focussed Models, rather than building giant, complex, inflexible Flows.

The Master Model is simply a model which combines Subflows into one large Model. Master Models are used to join together a range of system models, visualise them and test them as a whole.

## Related

- [Quality Modeller 101](/test-modeller-101.md)
- [Quality Modeller](/get-started-with-test-modeller.md)
- [Test Case Generation](/test-case-generation-in-test-modeller.md)
- [Browsing Test Cases](/browsing-test-cases.md)
- [Rule-Based Test Generation for an Individual Model](/rule-based-test-generation-for-an-individual-model.md)
