Skip to content

Switched Tests to the preCICE mock from a local Participant.cpp - #260

Draft
JulianHarrison-Wirth wants to merge 3 commits into
precice:developfrom
JulianHarrison-Wirth:develop
Draft

Switched Tests to the preCICE mock from a local Participant.cpp#260
JulianHarrison-Wirth wants to merge 3 commits into
precice:developfrom
JulianHarrison-Wirth:develop

Conversation

@JulianHarrison-Wirth

@JulianHarrison-Wirth JulianHarrison-Wirth commented Jul 21, 2026

Copy link
Copy Markdown

Main changes of this PR

Replaces the hand-written mock in test/Participant.cpp with the universal preCICE mock (libpreciceMocked.so, from extras/mock in the preCICE repository), and rewrites the test suite around it.

  • Removed test/Participant.cpp (260 lines of stubbed API returning fake values) and the MANIFEST.in/setup.py machinery that compiled it into the bindings. With PYPRECICE_MOCKED set, setup.py now simply skips linking libprecice; the symbols are provided at runtime by preloading the mock.
  • Added test/precice-config.xml — a real preCICE configuration (scalar/vector read and write data, a provided and a received mesh with API access, just-in-time mappings, a gradient mapping, a projection mapping, and a serial-explicit coupling scheme). The mock parses it and validates every API call against it.
  • tox.ini preloads the mock via LD_PRELOAD from PRECICE_MOCK_LIB and fails early with a clear message if that variable does not point at an existing library.
  • CI (.github/workflows/build-and-test.yml) builds the preciceMocked target from the preCICE checkout instead of copying Participant.hpp/Tooling.* out of it, and exports PRECICE_MOCK_LIB. libxml2-dev was added to the installed packages.
  • Test suite rewritten: 65 → 76 tests, now grouped by API area (construction, status queries, steering, mesh setup, connectivity, data access, just-in-time mapping, direct mesh access, gradient data, profiling). Tests no longer assert against constants hard-coded in a stub; they run a realistic lifecycle against the mock, and read_data returns what write_data wrote.
  • New coverage that the old stub could not express: error paths (unknown participant, missing configuration file, unknown mesh/data, writing data not configured for writing, reading before initialize(), invalid vertex IDs, setting vertices after initialize(), advancing beyond the time window), a full simulation loop with subcycling, checkpoint queries, mesh reset/remeshing, just-in-time mapping including the missing-access-region error, and profiling sections.

Motivation and additional information

The previous mock was a per-repository stub: it returned fixed values, knew nothing about a preCICE configuration, and therefore could only check that a call compiled and returned the expected constant. Anything configuration-dependent — error handling, coupling-scheme behaviour, correct read/write directions — was untestable, and the stub had to be kept in sync with the API by hand.

The universal mock validates calls against a real configuration and echoes written data back, so the bindings can be tested against behaviour instead of against constants, and the duplicated mock disappears from this repository.

Dependency on the preCICE PR

This depends on precice/precice#XXXX (extras/mock), which is not merged yet. Until then, the CI workflow clones the mock branch:

git clone --branch add-mocking-prototype https://github.com/JulianHarrison-Wirth/precice.git precice-core

There is a TODO next to it — the workflow must be switched back to --branch develop https://github.com/precice/precice.git once the mock is merged upstream. Please do not merge this PR before that is done.

Running the tests locally

# in a preCICE checkout containing extras/mock
cmake --build build --target preciceMocked
# in the python-bindings checkout
export PKG_CONFIG_PATH=/path/to/precice/build
export PRECICE_MOCK_LIB=/path/to/precice/build/libpreciceMocked.so
tox

Reviewers' checklist

  • Does the test configuration in test/precice-config.xml cover the API surface you would expect?
  • Is LD_PRELOAD via PRECICE_MOCK_LIB an acceptable way to run the suite, or should the mock be discovered automatically?
  • Should a CHANGELOG.md entry be added under ## latest?

@JulianHarrison-Wirth

Copy link
Copy Markdown
Author

Please Run the Tests again, it should work now

@IshaanDesai

Copy link
Copy Markdown
Member

Please Run the Tests again, it should work now

Done. The tests are now passing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants