# Run python test by the CI

**URL:** https://discourse.itk.org/t/run-python-test-by-the-ci/7597
**Category:** Engineering
**Tags:** python, ctest
**Created:** [July 17, 2025, 11:26am UTC](https://discourse.itk.org/t/run-python-test-by-the-ci/7597 "2025-07-17T11:26:01Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![axel\_garcia](https://discourse.itk.org/user_avatar/discourse.itk.org/axel_garcia/32/4396_2.png) [@axel\_garcia](https://discourse.itk.org/u/axel_garcia)
#### Post date: [July 17, 2025, 11:26am UTC](https://discourse.itk.org/t/run-python-test-by-the-ci/7597/1 "2025-07-17T11:26:01Z")

</div>

Hello, I’m working on the CudaCommon remote module and need an efficient way to test Python packages from generated wheels in our CI pipeline. Current options have limitations:

## The first approach with itk\_python\_add\_test

- Add Python tests using `itk_python_add_test` in the module’s CMakeLists.txt
- These tests run via CTest with a specific label: `ctest -L Python`.
- **Key issue:** This requires building ITK with Python wrapping enabled (`-DITK_WRAP_PYTHON=ON`), which is time-consuming.

## Alternative approaches I’m considering:

1. **Use pytest directly** as done in [ITKRemoteModuleBuildTestPackageAction](https://github.com/InsightSoftwareConsortium/ITKRemoteModuleBuildTestPackageAction/blob/main/.github/workflows/build-test-package-python.yml) for notebooks, but this disconnects the tests from CTest.
2. **Add a python-test flag in CudaCommon** , which simplify the configuration (I just have to configure CudaCommon with the flag enabled, see my [PR](https://github.com/RTKConsortium/ITKCudaCommon/pull/63)), but I would like to avoid creating new flags.

Has anyone developed an efficient workflow for testing Python-wrapped modules without rebuilding ITK each time? What approach do you recommend?

---

<div class="post-metadata">

### Author: ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [July 17, 2025, 8:25pm UTC](https://discourse.itk.org/t/run-python-test-by-the-ci/7597/2 "2025-07-17T20:25:44Z")

</div>

Hi @axel_garcia ,

When we build the `itk` python packages, we finish by:

- Testing installation of the built wheels
- Running a few tests with the contents of those wheels.

For example, on Linux:

> <https://github.com/InsightSoftwareConsortium/ITKPythonPackage/blob/4d07821a34b04917a821f05e6f76e8ca55767d1b/scripts/internal/manylinux-build-wheels.sh#L204-L213>

The ITKPythonPackage remote module build scripts could be extended to:

1. Install the built packages
2. Install pytest
3. Run `pytest` and have it discover any tests following pytest’s naming conventions.

---

<div class="post-metadata">

### Author: ![simon.rit](https://discourse.itk.org/letter_avatar_proxy/v4/letter/s/f08c70/32.png) [@simon.rit](https://discourse.itk.org/u/simon.rit)
#### Post date: [July 18, 2025, 1:32pm UTC](https://discourse.itk.org/t/run-python-test-by-the-ci/7597/3 "2025-07-18T13:32:59Z")

</div>

Thanks for your quick answer. If I understand correctly, ITK uses Python tests declared with `itk_python_add_test`, run by the CI e.g. in [`AzurePipelinesLinuxPython.yml`](https://github.com/InsightSoftwareConsortium/ITK/blob/main/Testing/ContinuousIntegration/) but you would not recommend using this for testing the Python code of remote modules but to prefer instead using `pytest`?

---

<div class="post-metadata">

### Author: ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [July 18, 2025, 2:02pm UTC](https://discourse.itk.org/t/run-python-test-by-the-ci/7597/4 "2025-07-18T14:02:41Z")

</div>

We have two types of functionality to test:

1. Are the wrappers we generate during development working correctly?
2. Are the packages we generate working correctly from an installation?

For the former, yes, `itk_python_add_test` makes CI and development possible. For the latter, testing after installation is desirable. It should be possible to use the same testing for both `itk_python_add_test` and pytest by naming the test files `test_*`.