Testing, CI/CD, and Native Build Validation

Aryanto
August 22, 2026
2 min read

Test layers

Model-specific tests should be supplemented with package import and backend checks:

pytest test/ary2tower_tests/ -v
pytest test/arycolbring_tests/ -v
python -m test.ltrlgbm_test.ltrlgbm_example

A broader source-tree run can include coverage and static checks appropriate to the repository checkout.

Ary2Tower native validation

A native build is not considered valid merely because build_ext exits successfully. The CI verification should prove that Python imports the generated modules and that the model actually routes work through them.

The source build is:

python ./src/cooprecsys/models/ary2tower/a2tcysetup.py build_ext --inplace

Then verify:

from cooprecsys.models.ary2tower.towers import backend_info
print(backend_info())

The runtime should identify the Cython/OpenMP backend when the compiled extensions are present.

Inference contract tests

Ary2Tower recommendation tests should cover more than score generation. In particular:

  • predict() returns paired user-item scores;
  • recommend(n_items=N) returns N unique rows whenever N eligible items exist;
  • exclude_purchased=True never returns purchased items;
  • explicit exclusions are respected;
  • the residual fallback fills shortfalls rather than returning a smaller list;
  • the fallback does not use item-item similarity;
  • both Cython and NumPy execution paths preserve the same public contract.

The only legitimate short result is when the eligible catalogue itself contains fewer unique items than requested.

Wheel validation

The wheel stage should validate:

  • wheel and sdist presence;
  • package version consistency;
  • extension-module presence for each CPython target;
  • isolated installation;
  • package import;
  • Ary2Tower backend import when a native wheel is expected;
  • twine check and release metadata.

Release pipeline

version metadata

Cython/OpenMP build matrix

wheel + sdist

isolated installation

import + backend + inference smoke tests

GitHub Release

PyPI publisher

Do not attempt to repair or replace native binaries during the publication job. The publish job should consume artifacts that have already passed compatibility tests.

Why backend tests matter

A common failure mode in Cython projects is: source compiles, package imports, but a different Python implementation is used at runtime. Checking backend_info() and exercising a real training/inference call catches that class of regression.

Last updated on August 22, 2026

Was this article helpful?

Your response is saved on this device.