Tag: Data Validation

Design and implement a testing strategy, including unit tests and integration tests (DP-800 Exam Prep)

This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Implement CI/CD by using SQL Database Projects
      --> Design and implement a testing strategy, including unit tests and integration tests


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

A successful database solution is not simply one that deploys successfully—it must also behave correctly, consistently, securely, and efficiently after deployment. As organizations increasingly adopt DevOps and Continuous Integration/Continuous Deployment (CI/CD) practices, automated database testing has become a critical component of modern database development.

For the DP-800 exam, Microsoft expects candidates to understand how testing fits into SQL Database Projects, Azure DevOps, GitHub Actions, and database deployment pipelines. Candidates should understand the differences between unit testing, integration testing, regression testing, performance testing, and validation testing, as well as how automated testing reduces deployment risk.


Why Database Testing Matters

Database testing helps ensure that:

  • Database objects compile successfully.
  • Business logic returns correct results.
  • Schema changes don’t break existing applications.
  • Stored procedures function correctly.
  • Data integrity is maintained.
  • Performance remains acceptable after changes.
  • Security settings remain intact.
  • Deployment scripts execute successfully.

Without testing, even small schema changes can introduce:

  • Broken stored procedures
  • Invalid foreign keys
  • Data corruption
  • Performance regressions
  • Failed deployments
  • Security vulnerabilities

Testing is therefore an essential component of every CI/CD pipeline.


Database Testing in a CI/CD Pipeline

A typical SQL Database Project pipeline follows this workflow:

Developer writes code
Commit to Git repository
Continuous Integration (Build)
Automated Unit Tests
Build DACPAC
Deploy to Test Environment
Integration Tests
Performance Validation
User Acceptance Testing (UAT)
Production Deployment

Testing occurs at multiple stages to detect issues as early as possible.


Types of Database Testing

Several testing categories appear throughout Microsoft’s documentation.

Testing TypePurpose
Unit TestingTests individual database objects
Integration TestingTests interactions between components
Regression TestingEnsures previous functionality still works
Performance TestingMeasures execution speed and scalability
Load TestingMeasures behavior under heavy workload
Security TestingValidates permissions and security
Smoke TestingBasic validation after deployment
Acceptance TestingConfirms business requirements are met

The DP-800 exam primarily focuses on unit testing and integration testing.


Unit Testing

What is Unit Testing?

A unit test verifies one small, isolated piece of functionality.

Examples include testing:

  • One stored procedure
  • One scalar function
  • One trigger
  • One view
  • One computed column
  • One business rule

A unit test should focus on only one object or behavior.


Characteristics of Good Unit Tests

Good unit tests are:

  • Small
  • Fast
  • Independent
  • Repeatable
  • Automated
  • Deterministic

A unit test should produce the same result every time it runs.


Example

Stored procedure:

CREATE PROCEDURE dbo.GetCustomerOrders
@CustomerID INT
AS
SELECT *
FROM Sales.Orders
WHERE CustomerID = @CustomerID;

Unit test verifies:

  • Valid customer returns rows
  • Invalid customer returns zero rows
  • NULL parameter handled correctly
  • Correct columns returned

Benefits of Unit Testing

Advantages include:

  • Finds bugs early
  • Easier debugging
  • Faster deployments
  • Lower maintenance costs
  • Safer code refactoring
  • Better documentation

Unit Testing Frameworks

Common SQL testing frameworks include:

  • tSQLt
  • SQL Test (Redgate)
  • SSDT Test Framework
  • Azure DevOps automated scripts
  • GitHub Actions test execution

Microsoft commonly demonstrates automated testing using SQL scripts executed within Azure DevOps or GitHub Actions.


tSQLt Overview

tSQLt is an open-source unit testing framework for SQL Server.

It provides:

  • Assertions
  • Test isolation
  • Mock objects
  • Fake tables
  • Automated execution

Example:

EXEC tSQLt.AssertEquals

Although DP-800 is not centered on tSQLt syntax, understanding that SQL unit testing frameworks exist is beneficial.


Integration Testing

What is Integration Testing?

Integration testing verifies that multiple database components work together correctly.

Examples:

  • Stored procedure updates multiple tables
  • Trigger fires correctly
  • Views join tables properly
  • API writes data successfully
  • ETL process loads data correctly
  • Application interacts with SQL database

Unlike unit testing, integration testing validates interactions rather than isolated components.


Example

Customer places an order.

Integration test validates:

Application
Stored Procedure
Orders Table
Inventory Table
Audit Table
Email Queue

Every component must function correctly.


Differences Between Unit and Integration Testing

Unit TestingIntegration Testing
Tests one objectTests multiple objects
FastSlower
IsolatedEnd-to-end
Few dependenciesMultiple dependencies
Easier debuggingMore complex debugging
Developer-focusedSystem-focused

Regression Testing

Regression testing verifies that new changes have not broken existing functionality.

Example:

Version 1:

Customer search works

Developer adds:

Email search

Regression testing verifies:

  • Customer search still works
  • Existing reports still function
  • Existing APIs still work

Regression tests are especially important before production deployments.


Smoke Testing

Smoke tests perform basic validation after deployment.

Typical smoke tests include:

  • Database accessible
  • Tables exist
  • Stored procedures compile
  • Views execute
  • Security objects exist
  • Basic queries succeed

Smoke tests determine whether further testing should continue.


Performance Testing

Performance testing validates:

  • Query execution time
  • Resource utilization
  • Index efficiency
  • Blocking
  • Deadlocks
  • Response time

Performance testing frequently uses:

  • Query Store
  • Execution Plans
  • DMVs
  • Extended Events

Performance testing should be included before production deployments.


Load Testing

Load testing measures behavior under expected workloads.

Examples:

  • 100 users
  • 1,000 users
  • 10,000 concurrent requests

Metrics include:

  • CPU utilization
  • Memory consumption
  • Wait statistics
  • Response times
  • Throughput

Security Testing

Security testing validates:

  • Authentication
  • Authorization
  • Row-Level Security
  • Dynamic Data Masking
  • Always Encrypted
  • Object permissions
  • Managed Identity access

Examples:

Verify:

SalesUser

cannot access

HR.EmployeeSalary

Test Environments

Testing should occur in multiple environments.

Typical environments:

Development
Build
Testing
Quality Assurance
User Acceptance Testing
Production

Each environment validates progressively more realistic scenarios.


Test Data

Reliable testing requires reliable data.

Test data should be:

  • Predictable
  • Repeatable
  • Isolated
  • Representative
  • Non-production whenever possible

Avoid using sensitive production data unless properly masked.


Database Mocks

Sometimes dependencies should be replaced.

Examples include:

  • Fake tables
  • Mock services
  • Test APIs
  • Sample datasets

Mocking allows tests to run independently.


Test Automation

Automated testing is one of the primary goals of CI/CD.

Benefits include:

  • Faster feedback
  • Consistent execution
  • Reduced human error
  • Repeatability
  • Higher deployment confidence

Automation should execute every time code changes.


Testing in Azure DevOps

Typical Azure DevOps pipeline:

Commit
Build SQL Project
Run Unit Tests
Generate DACPAC
Deploy Test Database
Run Integration Tests
Publish Results
Approve Deployment
Production

Failed tests should stop the deployment pipeline.


Testing in GitHub Actions

GitHub Actions workflows often include:

  • Build SQL Database Project
  • Create DACPAC
  • Deploy temporary database
  • Execute SQL scripts
  • Run automated tests
  • Publish results
  • Clean up environment

This supports fully automated DevOps workflows.


Continuous Testing

Continuous testing means testing occurs automatically throughout the development lifecycle.

Benefits:

  • Earlier defect detection
  • Lower costs
  • Faster releases
  • Improved quality
  • Better developer confidence

Test Coverage

Good test coverage includes:

  • CRUD operations
  • Stored procedures
  • Functions
  • Triggers
  • Views
  • Constraints
  • Security
  • Error handling
  • Transactions
  • Performance

Higher coverage reduces deployment risk.


Best Practices

Microsoft recommends:

  • Automate all repeatable tests.
  • Keep tests independent.
  • Use source control for test scripts.
  • Execute tests during every build.
  • Use representative test data.
  • Separate unit and integration tests.
  • Include regression tests.
  • Test deployment scripts.
  • Fail deployments when tests fail.
  • Review test results regularly.

Common DP-800 Exam Tips

Remember these key distinctions:

TopicKey Point
Unit TestTests one database object
Integration TestTests interaction among components
Regression TestVerifies existing functionality remains intact
Smoke TestBasic deployment validation
Performance TestMeasures speed and scalability
Load TestMeasures behavior under heavy usage
Security TestValidates permissions and protection
CI/CDAutomates builds, tests, and deployments
SQL Database ProjectSupports automated testing before deployment
DACPACDatabase deployment artifact that should be validated through automated testing

Summary

For the DP-800 exam, you should understand how testing strategies improve the reliability of SQL database deployments. Unit tests validate individual database objects, while integration tests verify interactions between multiple components. Automated testing is a fundamental part of CI/CD pipelines using SQL Database Projects, Azure DevOps, and GitHub Actions. A comprehensive testing strategy should also include regression, smoke, performance, load, and security testing. By automating tests and executing them during every build and deployment, organizations can reduce deployment risk, improve database quality, and deliver changes with greater confidence.


Practice Exam Questions

Question 1

A database developer wants to verify that a single stored procedure returns the correct results for various input values without involving other database objects. Which type of testing should be used?

A. Load testing

B. Integration testing

C. Unit testing

D. Regression testing

Answer: C

Explanation:
Unit testing validates a single database object or piece of logic in isolation. It is designed to verify that one stored procedure, function, or trigger behaves correctly under controlled conditions.


Question 2

A CI/CD pipeline deploys a DACPAC to a test database and then executes scripts that verify stored procedures, triggers, and application workflows function together correctly. What type of testing is being performed?

A. Integration testing

B. Smoke testing

C. Performance testing

D. Security testing

Answer: A

Explanation:
Integration testing verifies that multiple components interact correctly. It ensures database objects and applications work together after deployment.


Question 3

What is the primary purpose of regression testing?

A. Measure concurrent user performance

B. Verify that previous functionality still works after changes

C. Test database backups

D. Validate database security permissions

Answer: B

Explanation:
Regression testing ensures that new changes do not introduce defects into existing functionality. It is an important safeguard before production deployments.


Question 4

Which characteristic is considered a best practice for unit tests?

A. They should depend on production data.

B. They should require manual execution.

C. They should test multiple independent business processes simultaneously.

D. They should be repeatable and deterministic.

Answer: D

Explanation:
Good unit tests should produce consistent results every time they run, be independent of external factors, and execute automatically.


Question 5

Why should automated tests be included in every CI/CD pipeline?

A. To eliminate the need for version control

B. To automatically replace database administrators

C. To detect defects early and prevent faulty deployments

D. To remove the need for production monitoring

Answer: C

Explanation:
Automated testing provides immediate feedback on code changes, identifies problems early, and helps prevent unsuccessful deployments.


Question 6

A team wants to verify that a newly deployed database is accessible, key tables exist, and critical stored procedures execute successfully before running more extensive tests. Which testing approach should they use?

A. Regression testing

B. Load testing

C. Smoke testing

D. Unit testing

Answer: C

Explanation:
Smoke testing performs a quick validation that essential functionality is operational before more comprehensive testing begins.


Question 7

Which testing type is specifically intended to measure database behavior under thousands of simultaneous users?

A. Unit testing

B. Load testing

C. Regression testing

D. Static code analysis

Answer: B

Explanation:
Load testing evaluates how well a database performs under expected or peak workloads, measuring metrics such as throughput, response time, and resource utilization.


Question 8

Which statement best describes a unit test?

A. It validates interactions between multiple applications.

B. It verifies production backup procedures.

C. It measures database performance under heavy workloads.

D. It tests a single database object independently.

Answer: D

Explanation:
Unit tests focus on individual components such as stored procedures, functions, or triggers, allowing developers to isolate and troubleshoot defects efficiently.


Question 9

A SQL Database Project build fails because an automated test detects incorrect results from a stored procedure. What should the CI/CD pipeline do?

A. Continue deployment to production.

B. Ignore the test because the build succeeded.

C. Disable future automated testing.

D. Stop the deployment until the issue is corrected.

Answer: D

Explanation:
One of the primary benefits of CI/CD is preventing defective code from reaching later environments. Failed automated tests should stop the deployment pipeline.


Question 10

Why is representative test data important when designing a database testing strategy?

A. It guarantees maximum query performance.

B. It helps ensure tests accurately reflect real-world scenarios while avoiding unnecessary production data exposure.

C. It automatically creates execution plans.

D. It eliminates the need for integration testing.

Answer: B

Explanation:
Representative test data enables realistic testing while reducing the risk of exposing sensitive production information. Well-designed test datasets improve the reliability and usefulness of automated tests.


Go to the DP-800 Exam Prep Hub main page

Glossary – 100 “Data Quality & Data Validation” terms

Below is a glossary that includes 100 common “Data Quality & Data Validation” terms and phrases in alphabetical order. Enjoy!

TermDefinition & Example
 Business RuleBusiness-defined constraint on data. Example: Credit limit approval rules.
 Check ConstraintSQL rule enforcing condition. Example: Age > 0.
 ConstraintRule enforced at database level. Example: NOT NULL constraint.
 Continuous ValidationOngoing automated validation. Example: Streaming pipelines.
 Corrective ControlFixes identified errors. Example: Data reload.
 Data AccuracyDegree to which data correctly represents reality. Example: Correct customer addresses.
 Data Accuracy RatePercentage of correct values. Example: 99.5% accurate.
 Data AnomalyUnexpected or suspicious data value. Example: Sudden traffic spike.
 Data BiasSystematic data distortion. Example: Sampling bias.
 Data CertificationMarking trusted datasets. Example: Certified gold tables.
 Data CleansingCorrecting or removing invalid data. Example: Fixing malformed phone numbers.
 Data CompletenessPresence of all required data elements. Example: No missing customer IDs.
 Data Completeness RatePercentage of populated fields. Example: 97% filled.
 Data ConfidenceTrust users have in data. Example: Executive reporting trust.
 Data ConformanceAdherence to standards or schemas. Example: ISO country codes.
 Data ConsistencyUniformity of data across systems. Example: Same currency code everywhere.
 Data DeduplicationRemoving duplicate records. Example: Merge customer profiles.
 Data DefectSpecific instance of poor quality. Example: Invalid customer record.
 Data DriftGradual change in data patterns. Example: Customer behavior shifts.
 Data EnrichmentEnhancing data with additional attributes. Example: Adding demographic data.
 Data ErrorIncorrect or invalid data value. Example: Misspelled city name.
 Data ExceptionApproved rule deviation. Example: Legacy records.
 Data Exception HandlingProcess for managing violations. Example: Manual review.
 Data FreshnessHow current the data is. Example: Last updated timestamp.
 Data GovernanceFramework overseeing data quality. Example: Stewardship model.
 Data ImputationFilling missing values. Example: Replacing null with average.
 Data IntegrityAccuracy and consistency over the lifecycle. Example: Foreign key relationships enforced.
 Data IssueIdentified quality problem. Example: Missing values.
 Data LatencyDelay between event and availability. Example: 2-hour ingestion lag.
 Data LineageTracking data flow and transformations. Example: Source to dashboard.
 Data MatchingIdentifying records referring to same entity. Example: Customer record linkage.
 Data NoiseIrrelevant or misleading data. Example: Test records in prod.
 Data ObservabilityVisibility into data health and behavior. Example: Pipeline monitoring.
 Data OwnershipAccountability for data quality. Example: Business owner.
 Data PrecisionLevel of detail in data. Example: Decimal places.
 Data ProfilingAnalyzing data to understand structure and quality. Example: Null percentage analysis.
 Data QualityMeasure of how fit data is for its intended use. Example: Accurate sales totals in reports.
 Data Quality AlertNotification of quality issue. Example: Slack alert.
 Data Quality AuditFormal assessment of data quality. Example: Quarterly review.
 Data Quality AutomationAutomated quality processes. Example: CI/CD checks.
 Data Quality BacklogTracked list of quality issues. Example: Jira tickets.
 Data Quality BenchmarkComparison standard. Example: Industry averages.
 Data Quality DashboardVisual view of quality metrics. Example: Completeness trends.
 Data Quality DimensionCategory used to measure quality. Example: Accuracy, completeness.
 Data Quality FrameworkStructured quality approach. Example: DAMA dimensions.
 Data Quality IncidentMajor quality failure. Example: Incorrect financial report.
 Data Quality KPIMetric tracking quality performance. Example: Duplicate rate.
 Data Quality MaturityLevel of quality capability. Example: Reactive vs proactive.
 Data Quality MonitoringOngoing quality measurement. Example: Daily freshness checks.
 Data Quality Ownership MatrixMapping quality responsibility. Example: RACI chart.
 Data Quality ProgramOrganization-wide quality initiative. Example: Enterprise DQ strategy.
 Data Quality RegressionReintroduced quality issue. Example: After schema change.
 Data Quality Rule EngineSystem executing validation rules. Example: Automated checks.
 Data Quality Rule ViolationFailure to meet a rule. Example: Negative balance.
 Data Quality ScoreNumeric representation of data quality. Example: 98% completeness.
 Data Quality SLAQuality expectations agreement. Example: 99% accuracy target.
 Data Quality SLA BreachFailure to meet quality targets. Example: Accuracy below SLA.
 Data Quality TrendQuality performance over time. Example: Monthly improvement.
 Data ReconciliationComparing datasets for consistency. Example: Finance system vs warehouse.
 Data ReliabilityConsistent data performance over time. Example: Stable metrics.
 Data RemediationFixing data quality issues. Example: Reprocessing failed loads.
 Data SamplingChecking subset of data. Example: Random record review.
 Data StandardizationTransforming data into a common format. Example: Converting dates to ISO format.
 Data StewardRole responsible for data quality. Example: Customer data steward.
 Data ThresholdAcceptable quality limit. Example: ≤ 1% nulls.
 Data TimelinessData availability within required timeframes. Example: Daily data refresh by 6 AM.
 Data Trust ScoreComposite measure of reliability. Example: Internal trust index.
 Data UniquenessNo unintended duplicates exist. Example: One row per customer.
 Data ValidationProcess of checking data against rules. Example: Rejecting invalid dates.
 Data Validation PipelineAutomated validation process. Example: Ingestion checks.
 Data ValidityData conforms to defined formats and rules. Example: Email follows standard pattern.
 Data VerificationConfirming data accuracy. Example: Source system comparison.
 Detective ControlFinds errors after entry. Example: Quality audits.
 Domain ValidationRestricting values to a set. Example: Status = Active/Inactive.
 Downstream ValidationValidating analytical outputs. Example: Dashboard totals.
 Duplicate DetectionIdentifying duplicate records. Example: Same email address twice.
 Error RateProportion of invalid records. Example: 2% failures.
 Foreign KeyReference to another table. Example: Order → Customer.
 Format ValidationEnsuring correct data format. Example: YYYY-MM-DD dates.
 Golden DatasetHighest-quality dataset version. Example: Curated finance data.
 Hard ValidationBlocking invalid data. Example: Reject invalid IDs.
 Null CheckEnsuring required fields are populated. Example: Order ID not null.
 Outlier DetectionIdentifying abnormal values. Example: Negative revenue amounts.
 Pattern MatchingValidating via regex patterns. Example: Postal code validation.
 Post-Load ValidationChecks after data load. Example: Row count comparisons.
 Pre-Load ValidationChecks before data ingestion. Example: File schema validation.
 Preventive ControlStops errors before entry. Example: Input validation.
 Primary KeyUnique record identifier. Example: CustomerID.
 Quality GateMandatory validation checkpoint. Example: Before publishing data.
 Range ValidationChecking values fall within limits. Example: Age between 0 and 120.
 Referential IntegrityValid relationships between tables. Example: Orders reference valid customers.
 Root Cause AnalysisIdentifying source of data issues. Example: ETL failure investigation.
 Schema ValidationChecking data structure against schema. Example: Column data types.
 Soft ValidationWarning without rejecting data. Example: Flag unusual values.
 Source System ValidationChecking upstream data. Example: CRM record checks.
 Statistical ValidationUsing statistics to validate data. Example: Distribution checks.
 Trusted DatasetData approved for consumption. Example: Executive KPIs.
 Validation CoverageProportion of data checked. Example: 100% of critical fields.
 Validation RuleCondition data must satisfy. Example: Quantity must be ≥ 0.
 Validation ThresholdLimit triggering failure. Example: >5% nulls.