![Revisit consent button](../images/body-df29beacd7496220cc94.svg) We value your privacy We use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking "Accept All", you consent to our use of cookies. Customise Reject All Accept All Customise Consent Preferences ![](../images/body-2159bb67f3de8ad870eb.svg) We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below. The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... Show more NecessaryAlways Active Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data. * Cookie BCTempID * Duration 10 minutes * Description No description available. * Cookie __cf_bm * Duration 1 hour * Description This cookie, set by Cloudflare, is used to support Cloudflare Bot Management. * Cookie AWSALBCORS * Duration 7 days * Description Amazon Web Services set this cookie for load balancing. * Cookie _cfuvid * Duration session * Description Cloudflare sets this cookie to track users across sessions to optimize user experience by maintaining session consistency and providing personalized services * Cookie li_gc * Duration 6 months * Description Linkedin set this cookie for storing visitor's consent regarding using cookies for non-essential purposes. * Cookie __hssrc * Duration session * Description This cookie is set by Hubspot whenever it changes the session cookie. The __hssrc cookie set to 1 indicates that the user has restarted the browser, and if the cookie does not exist, it is assumed to be a new session. * Cookie __hssc * Duration 1 hour * Description HubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie. * Cookie wpEmojiSettingsSupports * Duration session * Description WordPress sets this cookie when a user interacts with emojis on a WordPress site. It helps determine if the user's browser can display emojis properly. * Cookie BCSessionID * Duration 1 year 1 month 4 days * Description Blueconic sets this cookie as a unique identifier for the BlueConic profile. * Cookie _octo * Duration 1 year * Description No description available. * Cookie logged_in * Duration 1 year * Description No description available. * Cookie __Secure-YEC * Duration past * Description YouTube sets this cookie to stores the user's video player preferences using embedded YouTube video * Cookie __eoi * Duration 6 months * Description Description is currently not available. * Cookie AWSALBTGCORS * Duration 7 days * Description No description available. * Cookie login-status-p * Duration past * Description Description is currently not available. * Cookie AWSALBTG * Duration 7 days * Description No description available. * Cookie csrf_token * Duration session * Description No description available. * Cookie token_v2 * Duration 1 day * Description Description is currently not available. * Cookie D * Duration 1 year * Description Description is currently not available. * Cookie PHPSESSID * Duration session * Description This cookie is native to PHP applications. The cookie stores and identifies a user's unique session ID to manage user sessions on the website. The cookie is a session cookie and will be deleted when all the browser windows are closed. * Cookie VISITOR_PRIVACY_METADATA * Duration 6 months * Description YouTube sets this cookie to store the user's cookie consent state for the current domain. * Cookie cookietest * Duration session * Description The cookietest cookie is typically used to determine whether the user's browser accepts cookies, essential for website functionality and user experience. * Cookie __Host-airtable-session * Duration 1 year * Description This cookie is used to enable us to integrate the services of Airtable. * Cookie __Host-airtable-session.sig * Duration 1 year * Description This cookie is used to enable us to integrate the services of Airtable. * Cookie m * Duration 1 year 1 month 4 days * Description Stripe sets this cookie for fraud prevention purposes. It identifies the device used to access the website, allowing the website to be formatted accordingly. * Cookie BIGipServer* * Duration session * Description Marketo sets this cookie to collect information about the user's online activity and build a profile about their interests to provide advertisements relevant to the user. * Cookie __cfruid * Duration session * Description Cloudflare sets this cookie to identify trusted web traffic. * Cookie _GRECAPTCHA * Duration 6 months * Description Google Recaptcha service sets this cookie to identify bots to protect the website against malicious spam attacks. * Cookie __Secure-YNID * Duration 6 months * Description Google cookie used to protect user security and prevent fraud, especially during the login process. * Cookie cookieyes-consent * Duration 1 year * Description CookieYes sets this cookie to remember users' consent preferences so that their preferences are respected on subsequent visits to this site. It does not collect or store any personal information about the site visitors. Functional Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features. * Cookie lidc * Duration 1 day * Description LinkedIn sets the lidc cookie to facilitate data center selection. * Cookie brw * Duration 1 year * Description No description available. * Cookie brwConsent * Duration 5 minutes * Description Description is currently not available. * Cookie WMF-Uniq * Duration 1 year * Description Description is currently not available. * Cookie loom_anon_comment * Duration 1 year * Description No description available. * Cookie loom_referral_video * Duration session * Description Description is currently not available. * Cookie VISITOR_INFO1_LIVE * Duration 6 months * Description A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface. * Cookie yt-remote-connected-devices * Duration Never Expires * Description YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. * Cookie ytidb::LAST_RESULT_ENTRY_KEY * Duration Never Expires * Description The cookie ytidb::LAST_RESULT_ENTRY_KEY is used by YouTube to store the last search result entry that was clicked by the user. This information is used to improve the user experience by providing more relevant search results in the future. * Cookie yt-remote-device-id * Duration Never Expires * Description YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. * Cookie yt-remote-session-name * Duration session * Description The yt-remote-session-name cookie is used by YouTube to store the user's video player preferences using embedded YouTube video. * Cookie yt-remote-fast-check-period * Duration session * Description The yt-remote-fast-check-period cookie is used by YouTube to store the user's video player preferences for embedded YouTube videos. * Cookie yt-remote-session-app * Duration session * Description The yt-remote-session-app cookie is used by YouTube to store user preferences and information about the interface of the embedded YouTube video player. * Cookie yt-remote-cast-available * Duration session * Description The yt-remote-cast-available cookie is used to store the user's preferences regarding whether casting is available on their YouTube video player. * Cookie yt-remote-cast-installed * Duration session * Description The yt-remote-cast-installed cookie is used to store the user's video player preferences using embedded YouTube video. * Cookie cp_session * Duration 3 months * Description Codepen sets this cookie for Help systems found in the website. * Cookie loid * Duration 1 year 1 month 4 days * Description This cookie is set by the Reddit. The cookie enables the sharing of content from the website onto the social media platform. Analytics Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc. * Cookie __hstc * Duration 6 months * Description Hubspot set this main cookie for tracking visitors. It contains the domain, initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session). * Cookie hubspotutk * Duration 6 months * Description HubSpot sets this cookie to keep track of the visitors to the website. This cookie is passed to HubSpot on form submission and used when deduplicating contacts. * Cookie _ga * Duration 1 year 1 month 4 days * Description Google Analytics sets this cookie to calculate visitor, session and campaign data and track site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognise unique visitors. * Cookie _ga_* * Duration 1 year 1 month 4 days * Description Google Analytics sets this cookie to store and count page views. * Cookie __Host-psifi.analyticsTrace * Duration 6 hours * Description Description is currently not available. * Cookie __Host-psifi.analyticsTraceV2 * Duration 6 hours * Description Description is currently not available. * Cookie _gh_sess * Duration session * Description GitHub sets this cookie for temporary application and framework state between pages like what step the user is on in a multiple step form. * Cookie YSC * Duration session * Description YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages. * Cookie ajs_anonymous_id * Duration 1 year * Description This cookie is set by Segment to count the number of people who visit a certain site by tracking if they have visited before. * Cookie vuid * Duration 1 year 1 month 4 days * Description Vimeo installs this cookie to collect tracking information by setting a unique ID to embed videos on the website. Performance Performance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors. * Cookie AWSALB * Duration 7 days * Description AWSALB is an application load balancer cookie set by Amazon Web Services to map the session to the target. * Cookie acq * Duration past * Description Description is currently not available. * Cookie acq.sig * Duration past * Description Description is currently not available. * Cookie ptc * Duration 2 years * Description No description available. Advertisement Advertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns. * Cookie muc_ads * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to collect user behaviour and interaction data to optimize the website. * Cookie guest_id_marketing * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. * Cookie guest_id_ads * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. * Cookie personalization_id * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to integrate and share features for social media and also store information about how the user uses the website, for tracking and targeting. * Cookie guest_id * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. It registers if a user is signed in to the Twitter platform and collects information about ad preferences. * Cookie bcookie * Duration 1 year * Description LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser IDs. * Cookie __Secure-ROLLOUT_TOKEN * Duration 6 months * Description YouTube sets this cookie to manage feature rollout and experimentation. It helps Google control which new features or interface changes are shown to users as part of testing and staged rollouts, ensuring consistent experience for a given user during an experiment. * Cookie yt.innertube::nextId * Duration Never Expires * Description YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. * Cookie yt.innertube::requests * Duration Never Expires * Description YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. * Cookie session_tracker * Duration session * Description This cookie is set by the Reddit. This cookie is used to identify trusted web traffic. It also helps in adverstising on the website. * Cookie edgebucket * Duration session * Description Reddit sets this cookie to save the information about a log-on Reddit user, for the purpose of advertisement recommendations and updating the content. * Cookie did * Duration 1 year * Description Arbor sets this cookie to show targeted ads to site visitors.This cookie expires after 2 months or 1 year. Uncategorised Other uncategorised cookies are those that are being analysed and have not been classified into a category as yet. No cookies to display. Reject All Save My Preferences Accept All Toggle Search[](https://towardsdatascience.com/)Toggle Mobile Navigation [](https://towardsdatascience.com/) Publish AI, ML & data-science insights to a global community of data professionals. Sign in[Submit an Article](https://write.insightmediagroup.io) [Latest](https://towardsdatascience.com/latest/)[Editor's Picks](https://towardsdatascience.com/tag/editors-pick/)[Newsletter](https://towardsdatascience.com/tag/the-variable/)[ShipAI](https://towardsdatascience.com/shipai/) * * * [Write For TDS](https://towardsdatascience.com/submissions/) [LinkedIn](https://www.linkedin.com/company/towards-data-science/)[X](https://x.com/TDataScience)Toggle Search # The SQL Unit Testing Landscape: 2023 Advancing speed and safety in SQL development [Chad Isenberg](https://towardsdatascience.com/author/cisenbe/) May 2, 202310 min read ![Photo by Ilse Orsel on Unsplash](../images/000.jpg) Photo by [Ilse Orsel](https://unsplash.com/@lgtts?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral) ## The evolution of SQL development Although SQL is nearly [50 years old ](https://en.wikipedia.org/wiki/SQL)(or perhaps _because_ it's nearly 50 years old), development in the language has been slow to adopt modern practices and tools. For decades, our primary "IDEs" were management tools like [SSMS](https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver16) and [DBeaver](https://dbeaver.io/), version control was accomplished via naming conventions like _stored_proc_2022_03 _15_ , and testing consisted of running your queries against production tables and exporting to a spreadsheet for manual reconciliation. But things have been improving rapidly over the last decade. Those database management tools, as well as cloud consoles for warehouses, are pretty feature rich with syntax highlighting, code completion, and plan visualizations. We have database versioning through tools like [Liquibase](https://docs.liquibase.com/home.html), [Flyway](https://documentation.red-gate.com/fd/welcome-to-flyway-184127914.html), and [dbt](https://docs.getdbt.com/docs/introduction). And even testing / auditing is less of a headache with things like [dbt-audit-helper](https://github.com/dbt-labs/dbt-audit-helper). One of the last frontiers is SQL [unit testing](https://en.wikipedia.org/wiki/Unit_testing), which is still very much in its infancy. Let's dive in! ## Why should we unit test? For those who have come into SQL development from outside of software engineering, the value of unit testing may not be immediately obvious. Typically, query development is a fairly fast cycle of "write query, run query, look at result set, modify query, repeat" But as your query complexity and data size grow, you run into some barriers. First, you can engage in a lot of redundant testing. Consider the following transform: sql ``` select id, case when order_count < 50 then 1 else 0 end as is_small_customer from customer ``` The query itself isn't exciting. But from a testing standpoint, what do we actually need to test, and what is being tested? We only need four records to cover our cases: * _order _count < 50_ * _order _count > 50_ * _order _count = 50_ * _order _count IS NULL_ Against your production database, you could be scanning millions or billions of records for your tests, and that can add up. You can (and should) have a development environment with a smaller subset of cleansed data, but this can still leave you with far more records than what you actually need to adequately test your queries. The other major issue is that even your full production dataset might not contain all reasonable test cases. Especially when you're onboarding a new data source, or if development or operations teams are changing how they generate data, it's entirely possible that you'll need test coverage for scenarios that don't yet exist in your data! Finally, the biggest dividends are earned during maintenance. When you need to make a change to existing functionality, a robust unit test suite will give you confidence that you're not breaking your queries. If your change breaks a unit test, you know that you have work to do: either change your query to preserve needed functionality, or modify your test to reflect the new logic. And since you're using very small mock datasets, you can get your feedback almost instantly while developing. Yes, you'll still need to do integrations testing and auditing, but with good test coverage, you can catch many of your errors before this stage, saving you time and compute costs. * * * To illustrate some of these ideas, here's a scenario. Let's say I'm working on a particularly complicated query that takes 30 minutes and $10 to execute against the production dataset. During the course of development, I have to execute the query 5 times as I make small adjustments, each time spending another $1 and 2 minutes while my audit query completes (noting that this step could be much more expensive if I manually audit results). As an average [American data engineer](https://www.salary.com/research/salary/listing/data-engineer-salary) making $120K / year, my time is approximately $57 / hour (ignoring taxes, benefits, etc.). My development cost $171 in labor and $55 in compute, for a total of $226. Implementing unit tests to cover the same query might take me an hour or two, since it's really complicated. But now my first 4 runs of the query are essentially free; since we'll be processing a handful of records, execution will take a handful of seconds, and I'm only on the hook for the final run for validation: $11 and 30 minutes of time ($28.50), for a total of $39.50. Combined with the unit test overhead, we're looking at $153.50, a savings of ~33%. There are plenty of counterarguments. What if the query only cost pennies and took seconds to run in the first place? What if I only had to make a trivial change and completed the work in one pass? What if I were working on a scaled-back development environment that cut my costs by half or more? Your specific use-cases may dictate how much value you can get out of unit testing, but I would argue that no matter your circumstances, you need to think about your testing strategy and the tradeoffs you're making. Testing incurs costs but is crucial to developing high-quality products; this is no different in the data world than it is in software. ## So where's our pytest equivalent? To answer the headline: there isn't one. Hopefully I've sold you on the idea that unit testing can give us the coverage we need with a very minimal amount of data. But of course, there's a catch. In the SQL world, what is a "unit"? For a language Python or Java, unit testing is frequently done at the method or class level; as the name implies, these are the most basic "units" of functionality that need to be tested. In SQL, is a unit the entire query? Is it a single CTE? A group of CTEs that convey some meaning together? The latter adds complexity to unit testing solutions since SQL isn't readily composable like general-purpose languages; you can't just "call" a CTE like you would a method. Good data modeling can help reduce this burden by making your queries more modular, but good test design is still challenging, and there are scarce best practices available. There are a number of pre-built options for SQL unit testing, but there's no standard at this point. There's an excellent [dbt thread](https://github.com/dbt-labs/dbt-core/discussions/4455) that details the benefits and potential approaches, but unfortunately, this isn't something that has made the roadmap just yet. Let's review some of the more popular options. ## tSQLt [tSQLt ](https://tsqlt.org/)is an open source project maintained by [Redgate](https://www.red-gate.com/), a big name in the SQL Server development space. Like a lot of SQL Server solutions, tSQLt is implemented as a series of stored procedures added as database objects into your target database. From the [tutorial](https://tsqlt.org/user-guide/tsqlt-tutorial/), here's a test of a stored procedure, with mocks handled as variables: sql ``` EXEC tSQLt.NewTestClass 'testFinancialApp'; GO CREATE PROCEDURE testFinancialApp.[test that ConvertCurrency converts using given conversion rate] AS BEGIN DECLARE @actual MONEY; DECLARE @rate DECIMAL(10,4); SET @rate = 1.2; DECLARE @amount MONEY; SET @amount = 2.00; SELECT @actual = FinancialApp.ConvertCurrency(@rate, @amount); DECLARE @expected MONEY; SET @expected = 2.4; --(rate * amount) EXEC tSQLt.AssertEquals @expected, @actual; END; GO ``` tSQLt also offers functionality for mocking tables and views, as well as asserting equalities, inequalities, and existence of various database objects. This tool is particularly well-suited to applications database development since, well, that's one of SQL Server's primary use-cases. You certainly _can_ apply this to analytics (and there are plenty of data warehouses implemented in SQL Server), but the focus is clearly on a different kind of development. ## dbt-unit-testing [dbt-unit-testing](https://github.com/EqualExperts/dbt-unit-testing) is a dbt package maintained by [Equal Experts](https://www.equalexperts.com/), a global technology consultancy. The approach is to create custom tests that utilize the package's macros, and then to run them. Here, mocks can be defined in query- or CSV-style, and some clever work with Jinja macros substitutes the mocks for the actual table references. From their docs: csharp ``` {{ config(tags=['unit-test']) }} {% call dbt_unit_testing.test('customers', 'should sum order values to calculate customer_lifetime_value') %} {% call dbt_unit_testing.mock_ref ('stg_customers') %} select 1 as customer_id, '' as first_name, '' as last_name {% endcall %} {% call dbt_unit_testing.mock_ref ('stg_orders') %} select 1001 as order_id, 1 as customer_id, null as order_date UNION ALL select 1002 as order_id, 1 as customer_id, null as order_date {% endcall %} {% call dbt_unit_testing.mock_ref ('stg_payments') %} select 1001 as order_id, 10 as amount UNION ALL select 1002 as order_id, 10 as amount {% endcall %} {% call dbt_unit_testing.expect() %} select 1 as customer_id, 20 as customer_lifetime_value {% endcall %} {% endcall %} ``` Once you've established your tests, it's as simple as running dbt test, and you get formatted output (also from the docs): sql ``` MODEL: customers TEST: should sum order values to calculate customer_lifetime_value Rows mismatch: | diff | count | customer_id | customer_lifetime_value | | ---- | ----- | ----------- | ----------------------- | | + | 1 | 1 | 20 | | - | 1 | 1 | 30 | ``` In addition to manually creating mocks, this package supports functionality to infer columns by directly querying your warehouse. In my personal experience, I had trouble getting this working, but this functionality could be very useful for wide tables, as you're otherwise on the hook for enumerating every single column. ## dbt-datamocktool [dbt-datamocktool](https://github.com/mjirv/dbt-datamocktool) is another dbt package that takes a slightly different approach. Mocks and expectations are created as seed files, and then tests are defined as inputs to the package's existing test in _schema.yml_ : css ``` models: - name: stg_customers tests: - dbt_datamocktool.unit_test: input_mapping: source('jaffle_shop', 'raw_customers'): ref('dmt__raw_customers_1') expected_output: ref('dmt__expected_stg_customers_1') depends_on: - ref('raw_customers') columns: ... - name: stg_orders tests: - dbt_datamocktool.unit_test: input_mapping: ref('raw_orders'): ref('dmt__raw_orders_1') expected_output: ref('dmt__expected_stg_orders_1') columns: ... ``` In addition to providing the mock data, you'll map the models' sources and refs to the appropriate mocks. This approach is more hands-on, but it's also more lightweight in terms of what it demands from your project. Unlike dbt-unit-testing, you don't have to override the _ref()_ and _source()_ macros with package-specific versions. The majority of the functionality is coming from dbt's native components: tests and seeds. The other exciting feature is support for incremental models for adapters that support the _MERGE_ operation. This is especially important in the dbt landscape since the incremental materialization fundamentally runs different queries depending on the "mode" of the dbt invocation; you need to be able to test both "versions" of the query for full coverage. ## SQLMesh A newcomer to the SQL modeling / templating space, [SQLMesh](https://sqlmesh.readthedocs.io/en/stable/) brings a ton of goodies, not the least of which is native unit test support. Tests are defined in YAML files and then executed on-demand or upon rebuilding of a SQLMesh plan. Mocking is straightforward, with mocks and expectations defined inside the same file. A killer feature I haven't seen elsewhere is the ability to test _individual CTEs_ : yaml ``` test_example_full_model: model: sqlmesh_example.example_full_model inputs: sqlmesh_example.example_incremental_model: rows: - id: 1 item_id: 1 ds: '2020-01-01' - id: 2 item_id: 1 ds: '2020-01-02' - id: 3 item_id: 2 ds: '2020-01-03' outputs: ctes: filtered_orders_cte: rows: - id: 1 item_id: 1 - id: 2 item_id: 1 query: rows: - item_id: 1 num_orders: 2 ``` As we saw with dbt-unit-testing, test output is visualized nicely: markdown ``` $ sqlmesh test F ====================================================================== FAIL: test_example_full_model (/Users/izeigerman/github/tmp/tests/test_suite.yaml:1) ---------------------------------------------------------------------- AssertionError: Data differs - {'item_id': 1, 'num_orders': 3} ? ^ + {'item_id': 1, 'num_orders': 2} ? ^ ---------------------------------------------------------------------- Ran 1 test in 0.008s FAILED (failures=1) ``` For me personally, this is the most compelling SQL unit testing option I've seen; however, it's also complicated by the fact that it's a SQL framework that isn't dbt. This is an early-stage tool facing a de-facto industry standard, and between feature gaps and adoption inertia (i. e., it has to be better by enough to get teams to switch), it's uncertain what its future holds. That being said, read the docs and get an idea of why, as impressive as the unit testing framework is, that's not even SQLMesh's best feature. ## Are we there yet? No. At the end of the day, the existing solutions are all pretty close in functionality and suffer from similar drawbacks. All of the tools do more or less the same thing: run your queries with mock inputs and compare the query output to an expectation. Some are more sophisticated than others in how they construct the test scenarios and generate output, but the differences are relatively small. There are three hurdles to adoption that I can see: 1. The industry hasn't coalesced around a standard. dbt has been remarkably successful even though it has significant and serious gaps (column-level lineage, unit testing, scalability); adoption has driven adoption. No unit testing solution has hit critical mass 2. The culture isn't there yet. SQL developers have been producing successful solutions for decades without access to unit testing. While the rise of the analytics engineer has brought more and more software engineering best practices to SQL development, it hasn't brought all of them, and unit testing is one of the gaps 3. Data mocking is still an unsolved problem. In all of the documented examples, we're looking at a handful of columns with simple relations between a handful of tables. Real queries can be orders of magnitude more complex. The developer feels the burden of many, sometimes dozens of join conditions and the referential integrity needed to make the tests pass. To some extent, this can be seen as a feature: i. e., the developer has to reason about every join and every record. But practically speaking, it's a slog, especially when real data that will just work is tantalizingly in reach I'm hopeful that the increasing number of conversations about the importance of testing, quality, and standards in the industry is pushing us toward more mature practices and better outcomes. When we can develop queries as safely and quickly as we can develop other software, we're going to unlock a lot of value. ## Register Now to Continue Reading ### Unlock Towards Data Science with a Free Account All articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more. Register for freeSign in to your account * * * ![](../images/body-9e4c3e3de7a22688d8ce.jpeg) Written By ## [Chad Isenberg](https://towardsdatascience.com/author/cisenbe/) [See all from Chad Isenberg](https://towardsdatascience.com/author/cisenbe/) Share This Article * [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ftowardsdatascience.com%2Fthe-sql-unit-testing-landscape-2023-7a8c5f986dd3%2F&title=The%20SQL%20Unit%20Testing%20Landscape%3A%202023) * [](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Ftowardsdatascience.com%2Fthe-sql-unit-testing-landscape-2023-7a8c5f986dd3%2F&title=The%20SQL%20Unit%20Testing%20Landscape%3A%202023) * [](https://x.com/share?url=https%3A%2F%2Ftowardsdatascience.com%2Fthe-sql-unit-testing-landscape-2023-7a8c5f986dd3%2F&text=The%20SQL%20Unit%20Testing%20Landscape%3A%202023) Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program. [Write for TDS](https://towardsdatascience.com/submissions/) * [YouTube](https://www.youtube.com/c/TowardsDataScience) * [X](https://x.com/TDataScience) * [LinkedIn](https://www.linkedin.com/company/towards-data-science/) * [Threads](https://www.threads.net/@towardsdatascience) * [Bluesky](https://bsky.app/profile/towardsdatascience.com) [](https://towardsdatascience.com/) Your home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals. Subscribe to Our Newsletter[Write For TDS](https://towardsdatascience.com/submissions/)•[About](https://towardsdatascience.com/about-towards-data-science-d691af11cc2f/)•[Advertise](https://contact.towardsdatascience.com/advertise-with-towards-data-science)•[Privacy Policy](https://towardsdatascience.com/privacy-policy/)•[Terms of Use](https://towardsdatascience.com/website-terms-of-use/) © Insight Media Group, LLC 2026•[The New Stack](https://thenewstack.io)•[roadmap.sh](https://roadmap.sh)•[Creator Network](https://insightmediagroup.io/creator-network)