Testing Guide - Mirobody

Overview

Mirobody’s tests are C++ unit tests written with Catch2 v3, living under tests/ and compiled into a single mirobody_tests binary. They are built by default and discovered by CTest.

The tests are a C++ Catch2 suite — the *_test.cpp files under tests/.

Running tests

Tests build as part of the normal build (the MIROBODY_BUILD_TESTS CMake option defaults to ON, except on Android / iOS):

./build.sh                      # builds the engine + tests
ctest --test-dir build          # run the whole suite via CTest

Or run the test binary directly and use Catch2’s filtering:

./build/tests/mirobody_tests                 # all tests
./build/tests/mirobody_tests "[fhir]"        # only the [fhir]-tagged tests
./build/tests/mirobody_tests "[transcode]"   # only transcoder tests

On Windows the binary is build\tests\mirobody_tests.exe. The build dir name follows your backend selector (e.g. build_sqlite/tests/mirobody_tests).

Test layout

Tests mirror the src/ module tree. Current coverage includes:

Area	Tests
FHIR	`tests/fhir/units_test.cpp` (UCUM normalization), `tests/fhir/resource_test.cpp` (resource validation)
Transcode	`tests/transcode/document_test.cpp`, `tests/transcode/image_test.cpp`, `tests/transcode/file_test.cpp`
LLM clients	`tests/llm/*` — SSE parser, OpenAI / Gemini / MiroThinker chat, realtime / live
MCP	`tests/mcp/tool_test.cpp`, `tests/mcp/resource_test.cpp` (tool / resource registration)
Chat	`tests/chat/agent_test.cpp`, `event_test.cpp`, `history_test.cpp`, `persist_test.cpp`
Infra	`tests/cache/`, `tests/jwt/`, `tests/oauth/pkce_test.cpp`, `tests/storage/`, `tests/memory/`, `tests/circle/`, `tests/utils/`

The test target links the self-registering objects (mcp_tools, mcp_resources, agent_impls) directly, the same way the app targets do — that’s what lets the registration tests observe compiled-in tools and agents.

Writing a test

Add a *_test.cpp under the matching tests/<module>/ directory, then list it in tests/CMakeLists.txt in the add_executable(mirobody_tests ...) sources.

#include <catch2/catch_test_macros.hpp>
#include "fhir/units/normalize.hpp"

using namespace mirobody::fhir::units;

TEST_CASE("UCUM normalization folds common spellings", "[fhir][units]") {
    REQUIRE(normalize_unit("MG/DL") == "mg/dL");
    REQUIRE(normalize_unit("mmHg")  == "mm[Hg]");

    ParsedQuantity q = parse_value_unit("<5.6 mg/dL");
    REQUIRE(q.comparator == "<");
    REQUIRE(q.value == Catch::Approx(5.6));
    REQUIRE(q.unit == "mg/dL");
}

Tag tests with [module] so they can be selected (mirobody_tests "[units]").

What the unit suite covers — and what it doesn’t

Pure / DB-free logic (the units engine, the FHIR resource validator, SSE parsing, PKCE, JWT, HMAC signing) is covered by fast unit tests with no external dependencies.
DB-backed paths (the FHIR REST handlers, chat persistence) are exercised end-to-end against a running server with a database, not in the unit binary.
Vendor clients have no unit tests in the suite — they call live third-party APIs, so they’re verified manually against a running server (see Provider Testing). Their metadata (VendorInfo) is credential-free and could be asserted, but transport is validated by hand.

Continuous integration

CI runs the build and tests on push. The pipeline is defined in the repository’s CI config (.gitlab-ci.yml). (verify the exact jobs in the repo.)

Next steps

Contributing

Build and change workflow

Provider Testing

Verify a vendor client by hand

Provider Integration

Add a new vendor::Vendor

File Processing

The transcoder and its tests

​Overview

​Running tests

​Test layout

​Writing a test

​What the unit suite covers — and what it doesn’t

​Continuous integration

​Next steps

Contributing

Provider Testing

Provider Integration

File Processing

Overview

Running tests

Test layout

Writing a test

What the unit suite covers — and what it doesn’t

Continuous integration

Next steps