# Vereinfacht tests – scope and rationale

## Constraint: no real API in CI

Tests do **not** call the real Vereinfacht API or a shared test endpoint. All tests use dummy data and either:

- Assert behaviour when **Vereinfacht is not configured** (ENV + Settings unset), or  
- Run the **full Member/User flow** with a **unreachable URL** (e.g. `http://127.0.0.1:1`) so the HTTP client fails fast (e.g. `:econnrefused`) and we only assert that the application path does not crash.

## What the tests cover

| Test file | What it tests | Why it’s enough without an API |
|-----------|----------------|---------------------------------|
| **ConfigVereinfachtTest** | `vereinfacht_env_configured?`, `vereinfacht_configured?`, `vereinfacht_contact_view_url` with ENV set/cleared | Pure config logic; no HTTP. |
| **ClientTest** | `create_contact/1` and `update_contact/2` return `{:error, :not_configured}` when nothing is configured | Ensures the client does not call Req when config is missing. |
| **VereinfachtTest** | `sync_members_without_contact/0` returns `{:error, :not_configured}` when not configured | Ensures bulk sync is a no-op when config is missing. |
| **SyncContactTest** | Member create/update with SyncContact change: not configured → no sync; configured with bad URL → action still succeeds, sync may fail | Ensures the Ash change and after_transaction arity are correct and the action result is not broken by sync failures. |

## What is *not* tested (and would need a stub or real endpoint)

- Actual HTTP request shape (body, headers) and response handling (201/200, error codes).  
- Persistence of `vereinfacht_contact_id` after a successful create.  
- Translation of specific API error payloads into user messages.

Those would require either a **Bypass** (or similar) stub in front of Req or a dedicated test endpoint; both are out of scope for the current “no real API” setup.

## Conclusion

Given the constraint that the API is not called in CI, the tests are **meaningful**: they cover config, “not configured” paths, and integration of SyncContact with Member create/update without crashing. They are **sufficient** for regression safety and refactoring; extending them with a Bypass stub would be an optional next step if we want to assert on request/response shape without hitting the real API.