From f99a9d4a429fc76c1ca9516d3243c71e25b0588a Mon Sep 17 00:00:00 2001
From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com>
Date: Wed, 8 May 2024 18:46:52 -0400
Subject: [PATCH] Unit test best practice

---
 website/docs/docs/build/unit-tests.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/website/docs/docs/build/unit-tests.md b/website/docs/docs/build/unit-tests.md
index d8eb195008b..ed0b58155a6 100644
--- a/website/docs/docs/build/unit-tests.md
+++ b/website/docs/docs/build/unit-tests.md
@@ -40,6 +40,12 @@ You should unit test a model:
 - Prior to refactoring the transformation logic (especially if the refactor is significant).
 - Models with high "criticality" (public, contracted models or models directly upstream of an exposure).
 
+### When to run unit tests
+
+We highly recommend only running unit tests in development or CI environments. Since the inputs of the unit tests are static, there is no need to use extra compute running them in production. Use them in development for a test-driven approach and CI to ensure changes don't break them. 
+
+Use the [resource type](/reference/global-configs/resource-type) flag `--exclude-resource-type` or the `DBT_EXCLUDE_RESOURCE_TYPE` environment variable to exclude unit tests from your production builds and save compute. 
+
 ## Unit testing a model
 
 This example creates a new `dim_customers` model with a field `is_valid_email_address` that calculates whether or not the customer’s email is valid: