Choosing Between Parameterized Connections and Wrapper Structs for Racket DB Mocking

Answer

The wrapper‑struct approach guarantees that make-connection never reaches a real database, regardless of the racket/db version. The parameterize technique is safe only when the library version exposes its connection arguments as parameters (releases ≥ 6.12).

Confirmed facts

• In racket/db ≥ 6.12 the keyword arguments (#:user, #:password, #:hostname, …) are read through corresponding parameters, so rebinding them with parameterize forces the driver to use the supplied dummy values and no network call is made.
• In releases prior to 6.12 those keyword arguments are not exposed as parameters; parameterize cannot override them, and the underlying driver may still attempt a real connection.
• A lightweight struct (e.g., struct test-db (user password db-name)) passed to a test‑specific query function lets you build a connection or call a mocked make-connection yourself, eliminating any reliance on the library’s internal parameter handling.

Likely explanation

If you wrap the test body in (parameterize ([make-connection-user "test"]) …) you are relying on an implementation detail that changed in version 6.12. When that detail is absent, the override is ignored and the driver may fall back to defaults or environment variables, risking a real network attempt.

The wrapper struct makes the dependency explicit: each query function receives the struct (or a connection factory) and decides how to obtain a connection. This requires updating call sites but gives the type checker a clear contract and avoids hidden reliance on library internals.

Steps for each approach

1. Parameterized‑connection (only for ≥ 6.12)
   1. Check the library version: (require racket/version) then (version).
   2. If the version is ≥ 6.12, wrap the test code:

      (parameterize ([make-connection-user "test-user"]
                         [make-connection-password "test-pass"]
                         [make-connection-hostname "localhost"])
              ;; your test that calls query functions
              )

   3. Verify safety by attempting a connection with obviously invalid credentials and asserting that an exception is raised (no timeout or successful connection).
2. Wrapper‑struct (works for any version)
   1. Define a struct to hold test connection data:

      (struct test-db (user password db-name) #:transparent)

   2. Modify each query function (or create a thin test‑only layer) to accept a test-db instance and use its fields to call make-connection or a mocked version.

      (define (run-query db sql)
            (define conn (make-connection #:user (test-db-user db)
                                         #:password (test-db-password db)
                                         #:database (test-db-db-name db)))
            ;; … use conn …
            )

   3. In tests, instantiate the struct with dummy values and pass it to the query function; no real connection will be made if you either stub make-connection or use a test database that is guaranteed to be isolated.
   4. Optionally, provide a production wrapper that extracts the same fields from a configuration record, keeping the change localized.

Impact on code change and static analysis

• parameterize: minimal change (just add the wrapper), but the overridden arguments are invisible to the type checker; a future change to make-connection's keyword list could silently break the override.
• Wrapper struct: requires updating each query call site (or adding a thin adapter), but the dependency is explicit, enabling better static analysis, easier refactoring, and clearer documentation of what data is needed for a connection.

Version‑specific caveats

For projects locked to racket/db releases before 6.12, the parameterize strategy cannot be trusted to prevent real connections; the wrapper‑struct method is the only safe choice. If you are unsure of the library version, obtain it as a diagnostic detail before deciding.