A city SQL Database Project for permit fees needs automated checks that fee-calculation procedures return expected amounts. Which CI/CD practice should they add?
Select an answer to reveal the explanation.
Short Explanation
Unit tests for fee procs are like running the cash register drawer with play money before Saturday rush—catch the wrong total in CI, not at the permit window.
Full Explanation
A city SQL Database Project for permit fees should include automated unit tests—commonly tSQLt-style or equivalent SQL unit testing—so fee-calculation procedures are asserted for expected amounts in CI before deployment. Embedding those tests in the project (or a tightly coupled test project) gives repeatable proof that municipal fee logic still calculates correctly after schema or procedure changes, which is the CI/CD practice the scenario asks for. Skipping tests and relying on production residents to report wrong fees is reactive and shifts detection past the point of citizen impact. Storing plaintext SQL passwords in the project accelerates nothing safely and violates secrets hygiene. Deploying straight to production from developer laptops without a pipeline bypasses the controlled build/test/release path Database Projects are meant to enable. Exam caveat: unit tests validate procedure logic in isolation; they do not replace integration tests against a deployed database or approval gates for production. tSQLt requires care in Azure SQL environments (permissions, CLR constraints historically on some platforms)—choose a testing approach supported on your target. Keep test data synthetic; never use live resident PII in CI. Operational check: add fee-calculation unit tests covering common, edge, and zero-amount cases; wire the test task into the CI pipeline so failures block merge; run the pipeline on a sample PR that deliberately breaks a fee formula and confirm red build; then fix and confirm green before promoting the dacpac.