Testing conceptual models

Documentation status: guide — see Maturity and evidence.

Testing a logiCells application means testing executable conceptual contracts. A useful strategy covers model loading, inheritance and implications, hypergraph and persistence facets, role paths, collection providers and joins, actions, publication, events, process states, view bindings, datasets, and service mappings.

Test the conceptual surface

Prefer assertions against public model identities and declared capabilities. A model test should instantiate representative objects, execute declared actions, observe events, and inspect resulting state. Avoid duplicating the implementation algorithm inside the test merely to compare two copies of the same logic.

A small functionalP assertion pattern is:

Self.Assert(
  GUnitTest,
  condition,
  'Message explaining the expected contract'
);

Assertion messages should name the protected contract, for example Start action is missing or PromptDefinition.Version metadata missing.

Contract categories

Published actions need contract tests for parameter names, directions, types, validation, results, and side effects. Process tests should protect observable states and transitions. Asynchronous behavior should be tested through emitted events or messages and deterministic state changes. View tests should validate cursor, dataset, data source, collection path, and action bindings before rendering details.

Evolution rule

Add or update a declarative test whenever a model change introduces or modifies a stable application contract.