Every workflow, bot or tool I hand over comes with two lists: what I checked, with where and how, and what I didn't check. The client should know which parts were tested against a real service and which ones only ran against a mock on my machine. Without that list, "it's tested" can mean almost anything, and the gaps show up later in production.
The labels I use
I keep my reusable components in a small library. Each one has a README covering purpose, inputs and outputs, setup and limits, along with code, fake sample data and a test suite. Its status lives in a registry file and uses one of four levels:
draft: not checked yet.unit_tested: the automated tests pass, using only mocks or fake data.verified: it ran on the real platform or API, with recorded evidence. That needs a test key or account.rejected: tried and dropped, with the reason written down.
Each entry also has a field called not_verified_against, which lists the platforms and conditions it was never run on. My rule is simple. If a platform appears in that field, I don't tell a client it was tested there.
As of 10 November 2026, the library has twelve components. Eleven are unit_tested, one is a draft, and none is verified. I'd rather show that plainly than round it up.
What the lists look like in practice
An n8n template that takes a webhook, validates the data and writes a row passed 9 of 9 tests on n8n 2.20.0 running locally. The "sheet" and the "alert" in that version are simulated: they write local files. So its not-checked list starts with Google Sheets, Telegram, concurrent load and a restart in the middle of a run. Testing also turned up a known issue: when a node fails, the webhook still returns 200 with an empty body. I wrote that down too, along with the note that an error branch is required before the template goes to a client.
A document question-answering component was tried with two small local models on fake documents. That is not a result anyone can rely on yet: the documents were fake, the models were small and local, and no commercial API or client data was involved.
An MT5 bridge that writes deal events to a file compiles with zero errors and zero warnings, and its logic matches a Python reference implementation. It has never run inside a terminal, so it is still a draft. Compiling cleanly only shows that the code builds.
The same idea on trading tools
For MetaTrader 5 utilities, each screenshot I publish says Checked or Not checked. Checked means I saw the behaviour work on a demo terminal or a Strategy Tester virtual account. For an equity protector, locking at the money limit and keeping the lock after a restart are checked. The percent and drawdown limits are not, and the label says so. None of these labels say anything about profit.
Why I bother
Writing the not-checked list changes how I work. If I can't name where something ran, I haven't really tested it, and I find that out before the client does. It also makes the next conversation easier. When I get a test account for a project, I know exactly what to run, and an item can move from unit_tested to verified with evidence behind it.
If you have a process you'd like automated, or an existing workflow you're unsure about, send me a description of how it runs today and which services it touches. I'll reply with what I could check locally and what would need access to your real accounts.