Test Suite

Kitto^x ships with a runnable automated test suite — 216 tests, green in all four build configurations (Win64 and Win32, Debug and Release). Version 4.0.19 is the first release validated with it, and several defects fixed in that release were found by it rather than by use.

If you build the framework from source, or maintain a fork, run it before you ship: it exercises your database adapters, your YAML parsing, and the metadata of your own applications.

Running it

Test\run_tests.cmd [Win64|Win32] [Debug|Release]

Both arguments are optional. The suite builds the test project and runs it, writing a DUnitX XML report next to the executable (Test\Bin\<platform>\<config>\dunitx-results.xml).

Run all four configurations

Assertions, range checks and overflow checks are off in Release. One defect found during the 4.0.19 cycle — a configured MaxUploadSize: 4096MB silently becoming 0, so no upload was allowed — was visible only in Release: in Debug the overflow raised, and the test accepted "raises" as an admissible outcome. A check that lives only in Debug is not a check.

What it covers

Area	What is tested
EF layer	Tree and YAML round-trip, macro expansion, string and system utilities, streams, SQL and JSON, logging
Databases	24 tests against real MSSQL, PostgreSQL, Firebird and Oracle servers
Metadata	The complete catalogue of the example applications — every model and every view
Master/detail	Detail records of a master that is not yet saved, and the master reference caption

Database integration tests

The connections live in Test\Data\TestDatabases.yaml, written in the same shape as an application's Databases node, so you can copy an entry from one to the other:

Databases:
  MSSQL: FD
    Enabled: True
    Connection:
      DriverID: MSSQL
      Server: 127.0.0.1, 1433
      Database: Taskitto
      User_Name: SA
      Password: ...

• A backend you set to Enabled: False is reported as skipped, with the reason, instead of failing. So is one that is enabled but unreachable — the suite has to stay meaningful on a machine that has only some of these engines installed.
• Read the skipped lines of a run: that is where a server which should have answered, and did not, shows up.
• The tests create and drop a table of their own (KX_TEST_TYPES), so the configured user needs permission to create tables. Point them at a development database: nothing here is meant to run against production data.

Metadata tests

The suite opens the metadata catalogue of HelloKitto, TasKitto and KEmployee and loads every object in it — which is what KIDE^x does when it opens a project, and what an application does on its first request. A view is only read from disk when something asks for it, so the test walks the whole index.

It then reads every property of every view through RTTI, including the main table and, recursively, the detail tables. That is the same path taken by KIDE^x's validator, the MCP tooling, and the render — one accessor at a time. A property that raises on a legitimate shape takes down whatever is walking, and this is the test that catches it.

Your application can be tested the same way

Both families of tests are driven by data, not by code: the databases from a YAML file, the metadata from the example applications' Home directories. Pointing them at your own application is a matter of configuration.