Now let us bring everything together into a realistic test project that exercises production code with mock data, runs under TestInsight during development, produces JUnit XML for CI, and detects memory leaks.
When your production code expects a TDataSet — whether it works with TClientDataSet, TkbmMemTable, a kbmMW dataset, or any other descendant — you can materialize the scenario as a dataset. AsDataSet returns a TClientDataSet; if your code under test requires a TkbmMemTable or kbmMW dataset instead, you can copy the data across or load the TkbmMemTable directly from the scenario’s fields:
unitTest.OrderReporting;
interface
uses
kbmTestFramework,
kbmTestDataSet,
kbmUnitTest.Mock,
kbmUnitTest.Mock.DataSet,
Data.DB,
Datasnap.DBClient;
type
[TestFixture('Order.Reporting')]
[Category('Unit')]
TTestOrderReporting=class
public
[Test('Report calculates correct line totals')]
procedureTestLineTotals;
[Test('Report produces correct grand total')]
procedureTestGrandTotal;
end;
implementation
uses
OrderReporting; // your production TOrderReport class
Because we set TkbmMockRegistry.SetSeed(42), this test is fully deterministic — if it fails on the 73rd iteration, it will fail on the 73rd iteration every time.
The Publish/Require Pattern
Some tests produce data that other tests depend on. The mock data system supports this through [TestScenarioPublish] and [TestScenarioRequire] attributes, combined with runtime publishing:
The framework’s dependency graph ensures that TestProcessOrder runs before TestShipOrder. If the publisher fails, the dependent test is skipped with a clear message.
PublishObject<T> works similarly for class instances:
One concern per fixture. Group related tests in a fixture. Name fixtures after the thing they test, not the test technique.
Name scenarios descriptively. Use customer_vip, order_empty_cart, product_out_of_stock — not data1, data2. Prefixes help avoid collisions between teams: billing_customer_standard, shipping_address_domestic.
Keep test data close to tests. A dedicated Test.MockData.pas unit (or a few organized by domain) is easier to maintain than scenarios scattered across 30 test units.
Use inheritance to reduce duplication. A “base” scenario with common fields and specialized scenarios that override only what differs.
Use categories for speed. Tag fast unit tests as 'Unit' and slow integration tests as 'Integration'. Run only 'Unit' during development; run everything on CI.
Enable leak detection early. Set lrmWarning during development, lrmFailure on CI. The retry mechanism handles false positives from lazy initialization.
Commit your test data. JSON fixture files should be in version control alongside your tests. They are as much a part of the project as the source code.
Use the wizard for initial setup, then maintain by hand. The Mock Data Wizard is great for bootstrapping scenarios from type declarations or database queries. Once generated, the code is yours to edit.
Quick Reference — Unit Map
Unit
When to use
kbmTestFramework
Always — attributes, Assert, fluent API
kbmTestRunner
Always — test runner, console/JUnit loggers
kbmTestInsight
IDE development with TestInsight
kbmTestDataSet
Asserting on any TDataSet — TClientDataSet, TkbmMemTable, kbmMW datasets, etc.
kbmTestFastMM5
Enriched leak detection with FastMM5
kbmTestFastMM4
Enriched leak detection with FastMM4
kbmUnitTest.Mock
Mock data: registry, scenarios, builder
kbmUnitTest.Mock.Generators
Value generators: Gen.*
kbmUnitTest.Mock.DataSet
Scenario → TDataSet bridge (returns TClientDataSet; use with TkbmMemTable / kbmMW via data copy)
kbmUnitTest.Mock.Diagnostics
Usage stats, near-miss detection
kbmUnitTest.Mock.Graph
Publish/Require dependency graph
Series Recap
Over six parts we have covered the full kbmUnitTest framework:
Getting Started — First test project, Assert class, RunTests.
TestInsight — Real-time IDE feedback with RunTestInsight.
Introduction to Mock Data — Named scenarios, materialization into records and objects, JSON/CSV loading, RTTI attributes.
Advanced Mocking — Inheritance, tabular data, generators, AsDataSet, the Mock Data Wizard.
Putting It All Together — Complete project structure, practical patterns, Publish/Require, diagnostics, CI/CD pipelines, best practices.
The framework is designed to grow with your project — start with Assert.AreEqual in Part 1 and add fluent chains, mock data, and CI integration as your needs evolve. Every piece is opt-in: use only the units you need, and the rest stays out of your way.
Happy testing!
kbmUnitTest is developed by Kim Bo Madsen at Components4Developers. Visit www.components4developers.com for the latest version and documentation.
