mitgliederverwaltung/test/mv/vereinfacht/vereinfacht_test_README.md

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.