Preprocessor mocks vs. dependency injection for credential-free Fortran integration tests

Recommended Approach

For a mixed-compiler HPC environment where production binaries must contain zero test artifacts and incur no runtime overhead, preprocessor mocks are the most reliable choice. While dependency injection (DI) offers better architectural elegance, the preprocessor approach is the only one that guarantees the complete removal of test-only code from the production binary at the compilation stage.

Risk Mitigation: Preventing Leakage

To minimize the risk of test code leaking into production, avoid scattering #ifdef guards throughout the core business logic. Instead, isolate the HTTP client behind a dedicated wrapper module. Use a single conditional switch in that wrapper to redirect calls to either the real client or the mock implementation:

! http_client_wrapper.f90
#ifdef TEST_MODE
    call mock_http_request(url, response)
#else
    call production_http_request(url, response)
#endif

By centralizing the switch, you reduce the surface area for configuration errors. Verification is performed by checking the production object files for the absence of mock-specific strings or symbols using nm or objdump.

Performance: Indirect Call Overhead

In the context of an HTTP client, the indirect-call overhead of dependency injection is negligible. Even if the client is invoked thousands of times per simulation step, the latency of a network request (or even a local mock response) is orders of magnitude higher than the few nanoseconds required for a procedure pointer dereference or a polymorphic method call.

The performance bottleneck in this scenario is the I/O operation, not the dispatch mechanism. Therefore, the decision should be based on binary purity and compiler compatibility rather than runtime overhead.

Implementation Steps for Preprocessor Mocks

1. Isolate the Client: Create a module (e.g., api_interface) that handles all external REST calls.
2. Define the Mock: Implement a separate api_mock module that returns canned responses.
3. Conditional Compilation: Use #ifdef TEST_MODE within the api_interface to select the implementation.
4. Build Configuration: In your CI/CD pipeline, pass the -DTEST_MODE flag to the compiler only for the test executable. Ensure the production build script explicitly omits this flag.

Missing Diagnostic: To refine this recommendation, please specify if your build system (e.g., CMake, Make) supports separate target definitions for production and testing, as this determines how strictly the preprocessor flags can be enforced.