My tests knew the language better than the platform did

I build client automations in Make, and for a recent build I wrote a small local evaluator for Make's expression language so I could test the logic before deploying it. The tests were green. On the first dry run in Make, a condition that combined three checks with a logical AND marked all seven test contacts as due for the wrong email. One of the three inputs was demonstrably false for every one of them. My evaluator computed AND. Make did not.

The test modelled the documentation

The automation decides which follow-up email a prospect gets next. The rule for one branch was simple: send this one if two flags are set and an event is active. In the run, the event flag was "0" for all seven contacts. The expression still returned "1" for each of them.

My local evaluator had parsed the same expression, applied AND the way every language I know applies it, and returned "0". It was not wrong about the language. It was wrong about the platform. I had written a test double of how the expression language should behave, and the test double was more correct than the thing it stood in for.

Nested conditions worked. A chain of if-statements, each testing one thing, returned the right answer in Make. Only the combined form failed.

Two more of the same kind

Once I knew to look, I ran small probe automations in Make itself, each one writing its result somewhere I could read back.

• **Empty is not equal to empty.** A check of the form "field equals empty string" was false when the field was empty. Make's own "if empty" function gave the right answer. My evaluator, again, gave the answer the code seemed to ask for.
• **Saved is not valid.** While searching the account, I found an automation that had been edited seven weeks earlier. Make had accepted the save and shown it as valid. It had not run since, because nobody had clicked the link that triggers it. My probe was its first run. It failed validation, did nothing, and Make deactivated it on the spot. The next five probe requests were answered with "accepted" and queued. Every real click in those seven weeks would have hit the same wall.

The last one is the dangerous one. A save that reports success and a webhook that reports "accepted" are two confirmations, and neither of them says the logic will run. Removing the one expression that combined a comparison with AND fixed it; the next probe ran six out of six.

Turning a surprise into a gate

Each finding went into the build script as a check that refuses to deploy:

• no AND or OR inside an expression, only nested conditions
• no comparison against an empty string, only Make's empty-check function
• after any expression change on a webhook-triggered automation, force one harmless run, with a filter that stops a known test address before anything is sent

Then I searched every automation in the account for the same patterns. Ninety-two automations, five with a real trap. The three active ones are rewritten; the two inactive ones have the fix ready for when they are switched back on. None of them had caused visible damage, because the affected branch either had no traffic or the field was never empty in practice. That is luck, not safety.

What I do differently

Local tests stay. The fixes above come with seventy of them, all green. They are fast, they catch typos and wrong field names, and they let me reason about the logic before the platform is involved. What they cannot do is tell me how Make evaluates the language. They compute the logic I intended. Whether Make computes the same thing, only a probe shows: a run on the platform that writes back what it computed.

I now treat every surprising platform behaviour as a rule with a test attached, rather than as something to remember. The next person to touch the build, including me in three months, will not remember. The gate will.