Testing

The default suite uses small deterministic RT-J checkpoints and realistic customer contexts containing typed customer, order, and support-ticket cells. It runs offline on CPU and finishes in a few minutes.

pytest

Coverage

The portable coverage gate requires at least 90% and excludes the CUDA-only Triton kernel implementations, which cannot execute on CPU CI. The current portable suite reports over 97%:

make coverage
What the default suite covers

  • typed relational batches, wide production-style node IDs, foreign-key parents, and padding;

  • classification, regression, batching, output views, and explicit support-ticket ablation;

  • checkpoint save/reload plus int8 and packed-int4 dequantization;

  • frozen-backbone binary and multiclass head tuning and full-model fine-tuning;

  • dynamic-batch and dynamic-context ONNX export and inference;

  • Triton sorting and relational attention work-list construction;

  • malformed shapes, missing fields, invalid semantic types, and non-finite values;

  • meta-device architecture inspection without parameter allocation.

Opt-in Suites

Published-model tests download large checkpoints from the Hugging Face Hub, so they only run when requested:

RUN_HUB_TESTS=1 pytest -m hub

On a CUDA deployment host, compare the optimized Triton output directly with the PyTorch backend on the same relational context:

RUN_CUDA_TESTS=1 pytest -m cuda

Linting and Documentation Checks

make lint      # ruff over the package and tests
make docs      # strict Sphinx build; any warning fails

Integration Testing

The RelativeDB repository has an additional end-to-end integration test. It runs a real PREDICT query through retrieval, cell encoding, relational batch construction, and this package’s PyTorch runtime.