Add transaction rollback tests for multi-step write operations #21

Open
opened 2026-04-20 09:37:14 +00:00 by sharang · 0 comments
Owner

Problem

After #9 (transaction wrapping) is merged, there are no tests that verify rollback actually happens when a mid-operation failure occurs. Without these tests, a future refactor could silently break atomicity.

Required Actions

  1. For each multi-step write operation identified in #9, add a test that:
    • Injects a failure (mock or DB constraint) at the second write
    • Asserts the first write was rolled back (record does not exist in DB)
  2. Key scenarios:
    • Change request creation fails mid-way: source document not modified
    • VVT + Loeschfrist creation: if Loeschfrist insert fails, VVT is rolled back
  3. Use pytest with real Postgres (transactional fixture)

Acceptance Criteria

## Problem After #9 (transaction wrapping) is merged, there are no tests that verify rollback actually happens when a mid-operation failure occurs. Without these tests, a future refactor could silently break atomicity. ## Required Actions 1. For each multi-step write operation identified in #9, add a test that: - Injects a failure (mock or DB constraint) at the second write - Asserts the first write was rolled back (record does not exist in DB) 2. Key scenarios: - Change request creation fails mid-way: source document not modified - VVT + Loeschfrist creation: if Loeschfrist insert fails, VVT is rolled back 3. Use `pytest` with real Postgres (transactional fixture) ## Acceptance Criteria - At least 3 rollback tests, each verifying atomicity of a different operation - Tests in CI, not skipped - Depends on: #9
sharang added this to the M4: Testing & Contract Stability milestone 2026-04-20 09:37:14 +00:00
sharang added the data-integrityseverity: mediumtesting labels 2026-04-20 09:37:15 +00:00
Sign in to join this conversation.