Why testing Flowable DMN decision tables needs its own plan
Rules in a decision table often change faster than the processes and cases that call them, and the people who change them are usually business owners, not the developers who built the surrounding application. A single wrong row can route a payment to the wrong approval path, send a case down the wrong stage or assign a customer to the wrong offer, and the process around it may still complete without error. That is why the decision table needs its own test plan, separate from the tests that cover the BPMN process or CMMN case that invokes it.
Flowable provides DMN as one of its decision rule engines, alongside its BPMN process and CMMN case engines. The engines are compact Java libraries licensed under Apache 2.0, so the DMN engine runs inside the same Java stack as your processes and can be exercised directly, without a user interface. A decision table takes input values, matches rules according to its hit policy and returns outputs. Testing the table means checking those input-to-output mappings in isolation: which rule fires for each combination, what happens at the boundaries of each input and what happens when two rules overlap. A passing process test only shows that the process completed, not that the rule returned the outcome the business intended. Teams should write a dedicated plan once a decision table governs money, eligibility, risk scoring or case routing, or once business owners edit it without a developer in the loop. The plan should name who approves each change, which test cases must pass before a deployment and how regression runs after each edit. Before you commit to a scope, confirm with your Flowable version and build tooling how deployed DMN files are loaded in your test environment, since that determines how close your tests can get to production behavior.
Which test layers catch which decision table errors
Unit tests deploy the DMN file to an engine and execute the decision with fixed inputs, then assert on the output. They confirm that the file parses, that the decision key resolves, that input and output column names match what the caller passes, and that a known input produces the expected result. Because the test runs the same deployed definition that production uses, it catches typos in expressions, wrong data types in input entries, and outputs that are missing from a rule. It cannot tell you whether the rule set is the one the business intended. A test written by the same person who wrote the table will often encode the same misunderstanding, and a passing test says nothing about inputs the author did not think to try.
- Parsing and deployment: the file must deploy without errors, and the decision key must resolve after deployment.
- Schema alignment: input and output names, types and required fields must match what the calling process or service sends.
- Expression errors: malformed FEEL expressions in input entries surface when a test evaluates a matching input.
- Blind spots: a unit test does not reveal overlapping rules or hit policy misuse unless a specific input happens to trigger the overlap.
- Engine version effects: run the same tests against the engine version you will run in production, because behavior can change between releases.
Before relying on unit tests, confirm with your team which Flowable engine version and DMN test helpers your build uses.
Rule-level test cases are written against each row of the decision table and each hit policy. For every rule, you choose an input that should match it and at least one input that should not, then check which outputs come back. This is the layer where hit policy errors show up. A FIRST table with two rows that both match an input returns one answer quietly, and a UNIQUE table with overlapping rows should fail for that input. Strict mode and collected outputs such as COLLECT or RULE ORDER need their own assertions, because the expected result is a list and the order matters. Coverage is judged by the rules, not by a count of test methods, so the useful question is whether every row has been matched by at least one case and every overlap has been deliberately tested.
- Row coverage: each row has at least one input that selects it and one that excludes it.
- Overlap detection: cases that match more than one row reveal whether the hit policy is the one you meant.
- Empty results: inputs that match no row show what the decision returns, and whether the caller handles that result.
- Ordering: for RULE ORDER and OUTPUT ORDER, assert the sequence of results, not only their membership.
- Boundary values: test values on both sides of each numeric threshold, such as the limit and one unit above and below it.
Rule-level cases cannot prove that the table covers every business situation. Ask business owners to review the case list and name the situations that are missing.
A regression suite is a stored set of inputs and expected outputs that runs on every change to a decision table. Its purpose is to show what a change altered, not only whether the new version works. When a rule is edited, the suite reveals outputs that changed for inputs that were not meant to change. Keeping the suite in version control next to the DMN files lets reviewers see both the rule diff and the output diff. A regression suite depends on its inputs: it only protects behaviors someone thought to record. It also cannot judge whether an expected output is correct, so a wrong baseline will be preserved until a reviewer corrects it.
- Golden inputs: capture representative production-like inputs, anonymized where personal data is involved.
- Output diffs: flag every case whose result changed between the old and new version.
- Approved changes: require a named reviewer to approve each intended change to an expected output.
- Version pinning: record which decision version each baseline came from, so comparisons are meaningful.
- Data limits: confirm with your data owners which inputs you may store in test fixtures and where they live.
Ask whether a changed output has a documented business reason before updating the baseline.
Integration checks execute the decision the way production does: from a BPMN business rule task, a CMMN decision task, or a REST call to the decision service. These checks confirm that process variables map to decision inputs correctly, that the output is read into the right variable, and that gateways route work as intended. Many production failures sit at this boundary, such as a variable that is null when the decision runs, a type mismatch between a process variable and a rule column, or a rule version that differs from what the team tested. Integration checks are slower and more brittle than unit tests, so they are usually limited to the main paths. They also do not replace rule-level cases, because a single process path rarely exercises every row.
- Variable mapping: confirm that each process variable reaches the decision input with the expected type.
- Result handling: check that the output drives the gateway or case transition it was designed for.
- Version selection: confirm which decision version a running instance uses after a deployment.
- REST contract: test status codes, error bodies and input validation for each decision endpoint your applications call.
- Authorization: confirm that only permitted callers can execute or deploy decisions, where your security design requires it.
Confirm with your platform team how decisions are deployed to each environment, because a passing check in a test environment proves little if production loads a different definition.
How to design test cases per rule and hit policy
Start from the decision table itself, not from the business story behind it. Each rule row is a claim the table makes about what result comes back for a given set of inputs, so each row needs at least one test that proves it fires for the input it describes and returns the output it states. Add a second test per row at the edges of its input conditions: the lowest and highest values in a numeric range, the first day of a date band, and the exact string or enumeration value that the row matches. Where a column uses an expression such as a comparison operator, test the value just inside and just outside the boundary, because off-by-one errors in these expressions are the most common defect that a visual review of the table misses. Include tests where an input is empty, null or absent, and confirm the result you expect from the table, since a missing variable in a Flowable process can produce a different outcome from what the business owner assumes.
The hit policy determines what a correct result looks like, so write the expected result shape before writing the input values. For FIRST and PRIORITY, a test must assert which single rule wins when several match, so you need overlap cases where two rows both qualify and the test checks that the earlier row or the higher-priority output is returned. For UNIQUE, the valuable test is the overlap case itself: the engine should reject a table that allows two rows to match, so confirm the error surfaces in your pipeline rather than in production. For ANY, overlapping rows are allowed only when they produce the same output, so test one overlap with matching outputs and one with conflicting outputs. For OUTPUT ORDER, RULE ORDER and COLLECT, assert the full list, including its order and whether duplicates are kept, because a list that is correct in content but wrong in sequence will pass a loose assertion and still break downstream logic. Confirm the exact behavior of each policy, including strict mode, against the Flowable DMN documentation for your version before you encode it in a test.
How to set up a decision table test pipeline
This sequence turns decision table changes into a repeatable release check, so each rule edit is deployed, exercised and verified against expected outputs before it reaches production. Each step produces an artifact or check that the next step relies on.
Keep DMN files in version control
The engineering team stores every DMN file in the same repository as the process and case definitions it serves, with one decision per file and a named owner for each decision key. Changes arrive through merge requests so the diff shows exactly which rule rows moved. The step is done when a rule change can be traced to a commit, a reviewer and a decision key. Ask your team whether your repository layout matches how Flowable decisions are deployed in your environment.
Deploy decision files to a test engine automatically
The build pipeline starts a Flowable engine in a test environment and deploys the DMN files from the commit under test. Teams using Spring Boot can run the DMN engine through the Flowable starters, while other stacks need their own bootstrap code, so confirm the setup your stack supports before committing to a design. The check at this step is that the deployment succeeds and that the deployed decision version matches the file under test. A mismatch stops the pipeline before any assertion runs.
Load a fixed input dataset for each case
Test authors define a fixed set of input cases for each decision, with one or more cases for every rule row, every hit policy edge case and every default or fallback path. Inputs are stored as versioned fixtures next to the DMN file, so the same data runs on every build. Business owners review the fixtures to confirm they reflect real policy outcomes. The step is done when every rule in the table has at least one fixture that would select it, and the coverage gap list is empty or explicitly accepted.
Execute decisions and assert outputs
The pipeline evaluates each decision with its fixture inputs through the engine's decision service and compares returned outputs with expected values written by the business owner. Assertions check the result and also the hit behavior, such as which rule matched and how many rows matched, because the hit policy defines what a correct result looks like. Failures report the decision key, the input row and the expected and actual outputs. The step is done when every fixture passes or each failure has a recorded reason.
Run the regression suite on every rule change
When a rule changes, the pipeline reruns the full fixture set for all decisions that depend on the changed file, not only the new cases. Expected outputs for unchanged inputs must stay the same unless the business owner has approved a policy change in the same merge request. The check is that no previously passing fixture changes result without an approved expectation update. This keeps side effects from overlapping rules visible before release.
Gate promotion on test results
The pipeline blocks promotion to the next environment unless the deployment check, all assertions and the regression run pass. Business owner approval is recorded as a required review on the merge request that changed the expectations. The gate produces a stored test report tied to the commit and the deployed decision versions, which serves as the release record. Confirm with your platform team how promotion gates and approvals are configured in your CI system.
Involving business owners in rule sign-off
Business owners should review the expected results before any DMN change reaches a release branch, because the test suite is only as correct as the outcomes it asserts. Ask each owner to read the decision table as plain-language test cases: a row of input values, a sentence describing the situation, and the expected output. For a decision with a hit policy such as FIRST or PRIORITY, the owner should also confirm which rule should win when two rules match, since the test case has to encode that intent explicitly. Keep these cases in a shared spreadsheet that the owner approves, and have the test code read from that same file so the approved wording and the executed assertions cannot drift apart.
Agree on who maintains the test data before the first sign-off. In most teams the business owner owns the expected-result spreadsheet and the engineering team owns the test harness that reads it, but you should confirm this split with your own governance and write it down. Each change that alters an expected result needs a named approver and a short reason, recorded in the same version control history as the DMN file. When an owner and a developer disagree about what a rule is meant to do, do not resolve it in the code. Log the disputed case as open, record both readings and the decision made, and have the owner who controls the policy confirm the outcome. Teams that work with auditors may also need this record as evidence of who approved each rule change, so confirm with your compliance lead what form that evidence must take.
Common gaps that let wrong decisions reach production
Most wrong decisions in production trace back to a few gaps: overlapping rules nobody tested, missing fallbacks, data types that differ between the test and the live system, and changed rules that were never run against known cases. Each card below names the gap and the check that closes it.
Untested hit policy overlaps
A table with a single-result hit policy such as FIRST or UNIQUE can look correct while two rules match the same input. Under UNIQUE the engine rejects the overlap at runtime, but under FIRST or PRIORITY the result depends on rule order, so a reordered row silently changes the outcome. Check: for every hit policy, write test cases where two or more rules match, and assert the exact result you expect. Confirm the strict mode behavior for your engine version in the Flowable docs before you rely on it.
Missing default rows
A decision table with no catch-all row returns no result for inputs nobody anticipated, and the calling process then takes an empty or null path at its gateway. The failure often appears only months later, when a new product code or region arrives. Check: every decision needs at least one test case with inputs that match no rule, and the test asserts how the calling process behaves with an empty result, not only that the decision runs.
Input type mismatches
A rule written as a number comparison will not behave as intended when the calling process passes the value as a string, because the input column type and the variable type must agree. Dates, decimals and booleans cause the same problem. Check: write tests that pass inputs with the same types your process actually sets, including values from forms and REST calls, and confirm the input column types in the DMN file match the variable types in the process.
Untested version changes
Deploying a new version of a decision does not by itself prove the change is correct, and a running process may pick up a version you did not test. Check: keep a regression suite of previously approved input and output pairs, run it against each new version before release, and record which version each test run covered. Review the deployment and versioning topic for how running instances choose a version.
Process code reading outputs incorrectly
The decision can return the right value while the process reads it wrong. A COLLECT or OUTPUT ORDER result is a list, and code that expects a single value may take the first element, the wrong column, or a null. Check: add integration tests on the process side that execute the business rule task and assert on the variables the gateways and later steps actually use, not only on the decision result.
Test data that drifts from production
Test fixtures written once and never updated stop reflecting real codes, currency values, and customer segments, so tests pass while production inputs fall outside what was covered. Check: refresh fixtures from anonymized production samples on a schedule, keep each fixture tied to the rule it covers, and have the business owner sign off on the expected results before the suite is treated as the release gate.
Testing options and when each fits
This table compares three ways to test a Flowable DMN decision table before release: in-process tests against the engine, calls through the REST decision endpoint, and spreadsheet-driven suites with a generated runner. Read each row against your team's skills and how often business owners change rules. Most teams combine an engine-level test per hit policy with a broader regression set.
| Option | What it verifies | When it fits | Trade-off |
|---|---|---|---|
| In-process engine tests | Deployed DMN files evaluate correctly against typed inputs, including hit policy results and empty-match behavior | Developers own the decision logic and want fast tests that run in the build pipeline | Requires Java test code per case. Confirm the test framework against the Flowable release in use, since 8.0.0 removed JUnit 3 and 4 support |
| Tests through the REST decision endpoint | The decision as other applications call it, including request shape, input mapping and response contract | The decision is exposed as a service and consuming teams need contract-level confirmation | Needs a running engine and deployment step, so tests are slower. Authentication for the test client must be set up in advance |
| Spreadsheet-driven suites with a generated runner | Business owners' expected outcomes for each row of example input, run against the deployed rule set | Business reviewers write and maintain expected results and want to see every case in one place | Generated runner code and the spreadsheet format need ownership. Expected values can drift from the DMN file if the sheet is not regenerated |
| Hit policy coverage cases | Overlapping rules resolve as the hit policy intends, such as FIRST ordering or UNIQUE violations | Any table that uses a non-default hit policy or relies on rule order | Each policy needs its own deliberate cases. Easy to under-test when only the happy path is written |
| Regression suite on rule change | Previously approved outputs stay the same after an edit, except where a change was intended | Rules change often without a process redeploy and the cost of a silent regression is high | Stored expected outputs must be reviewed when intended changes land, or the suite becomes noise |
| Review by business owners | Rule meaning matches the policy text, using examples the owner recognizes | Before any release that changes thresholds, eligibility or pricing logic | Depends on owner time and availability. Record sign-off so the approved version is traceable |
| Engine-level version check | Which decision version a deployment exposes and that older versions still resolve for running work | Rules are versioned separately from processes and running instances must keep their version | Requires test data that spans deployments. Confirm the behavior against your Flowable version |
Security and data handling in decision test suites
Decision test suites run against real rule logic and often real customer attributes, so they carry the same data and access risks as the process they support. The four cards below cover the controls to agree with your security and compliance teams before the first test case is written.
Personal data in test inputs
Decision tables usually take inputs such as income, age, postcode or account status, and those values can identify a person even when no name is present. Test cases built by copying production payloads move personal information into repositories and CI logs. Use synthetic input sets that cover each rule's boundaries, and confirm with your privacy team whether any anonymized extract is acceptable. Ask who approves the source of every fixture file that enters the repository.
Access to test engines
A test engine that loads the same DMN files as production can also be used to probe rule logic, so its access should match the sensitivity of the decisions it executes. Limit who can deploy definitions to test environments and who can call the REST endpoints with real-looking payloads. Confirm how your identity provider maps reviewers and developers to Flowable roles, because the engine does not decide who may run which decision for your application.
Separate test and production history
Flowable records DMN execution history, and test runs written to the same database will mix synthetic decisions with real audit trails. That can distort troubleshooting and weaken evidence for auditors who sample production records. Point test suites at a dedicated schema or database, and confirm how history is partitioned by tenant or environment. Also check how long test history is kept and who can purge it.
Secrets in CI pipelines
Test pipelines often need database credentials, identity tokens or REST client secrets to start an engine or call a decision service. Storing these as plain variables in pipeline files exposes them to every contributor with repository access. Use your CI system's secret store, scope secrets to the test environment, and rotate them on the same schedule as other service accounts. Ask your platform team to confirm that pipeline logs mask these values and that forked or external pull requests cannot read them.
Questions teams ask about testing Flowable decision tables
How much effort does a Flowable decision table test suite take?
Effort depends mostly on how many decision tables you have, how many rules each table contains, and how many hit policy behaviors and input combinations you need to prove. A table with a handful of rules and a single FIRST hit policy needs a small set of cases. A table with dozens of rules, COLLECT outputs and overlapping conditions needs boundary cases for every rule, plus cases for overlaps and empty results. The one-time cost is building the harness and the first cases. The recurring cost is maintaining cases each time a rule changes. Ask any partner to break its quote into harness setup, case authoring per decision and review time with your business owners.
Can business owners write the test cases themselves?
Yes, for many teams, provided the test format is simple enough for them to read and the engineers own the harness. Business owners are usually best placed to state the expected outcome for a given customer, product or region, because they know the policy behind each rule. Engineers should turn those examples into repeatable tests that load the deployed DMN file and assert the output. Plan a review step where owners sign off on expected results before the cases become part of the release gate. Confirm with your own team how much DMN syntax they are willing to read.
How long does a regression run take, and what affects it?
Run time is driven by the number of decision tables, the number of cases per table, and whether the tests start a full engine or call the DMN engine directly. Decision evaluation is usually fast in isolation, so the main cost is often engine startup and database setup in your pipeline. Tests that deploy many DMN files for each case run slower than tests that deploy once per suite. Ask for the expected run time in your environment and measure it on your own CI runners before you set a gate, because the result depends on your hardware, database and parallelism.
Can our own team build this testing setup without a partner?
Many teams can, especially if they already run Java tests and Flowable is embedded in their application. The core work is standard: add the Flowable DMN engine to the test classpath, deploy the DMN files under test, execute decisions with known inputs and assert the results. The harder parts are case design for hit policies, a review workflow with business owners, and a regression suite that keeps pace with rule changes. Your team will need time for these, and Flowable's version changes can affect the test setup. Check the release notes for your target version before you start.
What does the work need from our team?
You need a named engineering owner for the test harness, access to the DMN files and their change history, and at least one business owner for each decision table who can confirm expected results. You also need your build pipeline access, a test database where needed, and agreement on which Flowable version you target. For a fixed-scope engagement, the written scope should list which decisions are covered, who signs off on expected outcomes and where the tests run. Confirm these inputs before the work starts so that scope and timelines match your team's availability.
Does a decision test suite replace audit evidence?
No. A passing test suite shows that a decision table behaves as the test cases describe, which helps with change control and regression. It does not by itself prove that the rules meet your regulatory obligations, and it does not replace the audit trail that shows which rule fired for a live case. Auditors and certification bodies decide what evidence they accept. Use the test results as one input, keep the test cases and approval records under version control, and pair them with DMN decision history where your policy requires it. DeployOpen prepares systems and evidence for assessments but does not issue audit reports.
How DeployOpen scopes and delivers Flowable decision testing
DeployOpen treats decision table testing as part of the Flowable delivery, not a separate afterthought. We agree the decisions, hit policies and test evidence in writing first, then build and hand over a test suite your team can run on every rule change.
How we scope
- Inventory the decision tables in scope, their hit policies and the process or case tasks that call them
- Agree which rules need unit tests, which need regression coverage and which need business owner sign-off
- Confirm the Flowable engine version and Java, Spring and build tooling the test suite must run on
- Record the scope, deliverables and timeline in writing before work starts, as engagements are fixed-scope
How we build
- Write test cases per rule, covering each hit policy and the overlaps it is meant to tolerate or reject
- Load the deployed DMN files in tests so the suite exercises the same definitions production uses
- Add regression tests that capture current outputs so rule changes show their effect before release
- Run the suite in your build pipeline and keep test data and expected results under version control
How we hand over
- Deliver the test suite, a map of rules to test cases and the procedure for adding new rules
- Document the review steps for business owners, including who approves expected results and how sign-off is recorded
- Walk your engineers through running, extending and interpreting the tests on your own infrastructure
- Provide a written list of open items, such as rules that still lack owner confirmation
How we support
- Keep test coverage aligned with rule changes through a retainer if your team wants ongoing help
- Re-run and update regression suites when Flowable versions or dependencies change, as part of agreed scope
- Review test failures with your team and agree fixes in writing before changing expected results
- Use ongoing testing support to extend coverage as new decision tables and hit policies are added
