A public library SQL Database Project issues card numbers with a SEQUENCE and CHECK constraints. What should unit tests in the project cover?
Select an answer to reveal the explanation.
Short Explanation
Card numbers and CHECKs are the library’s ticket printer rules—unit tests should prove the SEQUENCE and constraints behave before anyone swipes a new card in prod.
Full Explanation
A public library SQL Database Project issues card numbers with a SEQUENCE and CHECK constraints. Unit tests in the project should cover SEQUENCE generation and constraint enforcement for those card-issuance objects—proving next values allocate as designed and invalid card attributes are rejected. Municipal library systems depend on stable identifiers and rule enforcement; project-level unit tests catch regressions in object behavior before CI packages a dacpac for higher environments.
Skipping object tests because sequences never fail in municipal systems fails by assumption: sequences, seeds, and permissions do fail or drift, and untested objects ship silent defects. Testing only CI YAML syntax while ignoring database object behavior fails scope—the stem is about SEQUENCE and CHECK rules on card issuance, not pipeline file lint. Validating UI themes for the catalog app instead of SEQUENCE and CHECK rules fails by testing the wrong layer; presentation themes do not prove database constraint correctness.
Exam caveat: SQL Database Project testing questions distinguish database object unit tests from pipeline-definition checks and application UI tests. When the stem names SEQUENCE and CHECK on card numbers, the answer must exercise those objects.
Operational check: add project tests that allocate multiple card numbers from the SEQUENCE and assert uniqueness/monotonic expectations appropriate to the design, then attempt inserts that violate CHECK rules and assert failure. Run the tests in CI on each PR so library schema changes cannot merge when card-issuance behavior regresses.