Two people can’t hand-write a test suite for a warehouse. They can test the part of it that would get them fired, and they can do it in a week.
The common first move is the wrong one. Somebody opens the dbt project, adds unique and not_null to three models, and calls it a start. Six months later it’s still three models. That matches what we found when we read 849 comments on why data engineers don’t test: time is the top reason, and testing loses to feature work every sprint.
The arithmetic that rules out hand-writing
Where to Actually Start with DataOps in 2026 does the math. A bronze layer of 100 tables averaging 10 columns needs roughly 200 table tests and 2,000 column tests, and silver and gold want their own. At 30 minutes per test, that’s months of typing. The Guide to DataOps Tests runs the same sum on a full Medallion build and lands at roughly 5,000 tests.
dbt tests, Great Expectations, and Soda make each test quicker to write. They don’t change the count, because every test still starts as code. The baseline has to be generated. Your two people write the part a profiler can’t.
A first-week plan
| Day | Do this | What you have at the end |
|---|---|---|
| 1 | List the tables where a wrong number reaches someone who can escalate it. Usually a couple dozen, not 4,000. | A short list, each table with a reason |
| 2 | Profile those tables. Read the hygiene issues before anything else. | A dated baseline of what the data looks like today |
| 3 | Generate baseline tests from the profile. Mark hard constraints as hard fails; set statistical checks to warn-only. | Hundreds of tests you didn’t type |
| 4 | Take the profile to the analyst who reads each report. Draft one business rule per key metric and let them correct it. | The rules no generator can infer |
| 5 | Give every check one owner and a severity. Schedule the suite to run after each load. | A suite that tells a named person when something breaks |
Days 2 and 3 are where the tool matters. DataOps TestGen profiles every column on 55 characteristics, runs 32 hygiene detectors, and generates tests from 34 test types. The open source version is free and covers one user, one connection, and one project. A second user needs Enterprise at $100 per user and $100 per connection per month (see pricing). Other tools generate tests too. What matters is that the baseline isn’t typed.
Day 4 is the one teams skip. A profiler can tell you a column is 3% null. It can’t tell you that when active members drop while claim volume holds flat, the eligibility file truncated. Asking the analyst to write rules from a blank page gets you four rows back, two of which say the data should be accurate. Showing them a draft to correct gets you real rules in minutes.
Why day 4 can’t be skipped
Generated tests learn what’s normal, including what’s normally wrong. In DataKitchen’s NYC taxi exercise, 62 generated tests passed on a 300,000-row sample, partly because the minimum-fare test set its floor at negative $367. Seven AI-written business rules failed on that same sample. On the full 2,964,624 rows, 11 of 69 tests failed: those seven rules plus four generated minimum-value tests. The rule “fares are never negative” is one sentence. No profile writes it for you.
Keep the loud tests few
The fastest way to kill a new suite is to page someone for every statistical wobble. Split the tests on day one: hard constraints you know are true fail loudly, and distribution and volume checks run warn-only for a couple of weeks before you promote them. Which checks should a small team set up first has the full starter list with severity and owner for each.
By Friday you won’t be covered. You’ll have tests on the tables that matter, owned by people who’ll act on them, and the next bad load will reach you before it reaches finance.