Integration tests need a real SQL Server engine in CI. Each run must start from the same schema and seed data, and no run may affect a later one. Which approach meets this?
Show answer and explanation
Answer: C
Service containers start a dependency beside the job and tear it down when the job finishes. Pairing a versioned SQL Server image with a fixed set of migration scripts gives every run the same starting state, and discarding the container prevents leftover data from affecting later builds. The tests run against the real engine rather than a stand-in. Shared databases carry state between runs, SQLite behaves differently from SQL Server, and scheduled runs delay feedback.
Why the other options are wrong
- A. A shared database accumulates data and changes from testers and other pipelines, so results depend on what ran previously. Failures become hard to reproduce.
- B. SQLite differs from SQL Server in data types, collations and SQL dialect, so passing tests may still fail in production. The stand-in does not validate the real engine.
- D. Running tests weekly delays discovery of defects by days and lets broken queries reach the main branch unnoticed. Isolation is achievable without giving up frequent feedback.