API tests for a building-permit service need known rows in the test DynamoDB table before each run. How should that data be prepared?
Select an answer to reveal the explanation.
Short Explanation
Set the chessboard the same way before every match. A seeding script with anonymized fixtures makes API tests repeatable. Cloning prod PII or typing rows by hand is messy and unsafe.
Full Explanation
API tests for a building-permit service need known rows in the test DynamoDB table before each run, prepared by a repeatable seeding script that loads anonymized fixture permits. Automating test-data preparation is part of environment testing: versioned seeds create a known municipal baseline without cloning production personal data into lower environments. Empty tables, production clones, and hand-typed console rows produce flaky or non-compliant suites.
Copying the entire production table into test before every suite, including personal citizen data, fails because it exposes PII and makes tests depend on live production contents that change underfoot. Leaving the test table empty and asserting only that HTTP 500 responses are interesting fails conceptually—500s are not a substitute for known fixture assertions. Asking QA to type fixture permits into the console whenever a test fails fails as manual, non-repeatable setup.
Exam caveat: seeds should be idempotent or reset state explicitly so parallel pipeline runs do not collide on the same primary keys. Operational check: run the seed script in CI before API tests, assert fixture IDs exist, execute tests, and optionally truncate or re-seed afterward to keep the test account tidy.