How do you test a routine before relying on it?

Four states

Locked. The most common real condition and the one that fails, since tag dispatch generally needs an awake unlocked device.

Busy. During a call, a video, a full screen application. The read usually works and the action may be deferred or dropped.

After a restart. Automation applications sometimes need to be opened once before they resume, which is invisible until a phone restarts overnight.

A week later. Battery optimisation and permission resets act on a delay, so a routine can work all week and stop on the eighth day.

The week matters

Most routine failures are not immediate. They arrive when the system decides the automation application has been idle, or when a permission is reviewed.

So a routine tested thoroughly on the day it was built can still fail on the day you first depend on it.

Use it for a week before it becomes the only way you do something.

And note the date you built it, because a failure a month later is much easier to diagnose if you know what changed and when.

Watch the outcome

Confirm that the thing you wanted actually happened, not that the phone reacted.

For a chain, check every step, since a partial run is the failure that hides. Three of five steps completing looks like success.

For anything with a delay, wait for it. A timer that starts and never alerts has failed at the only moment that counted.

And test it once with somebody else present, because you have learned to hold the phone in a way they have not.

Before relying on it

Keep the manual route available. An automation that removed the ordinary way of doing something has no fallback when it fails.

Do not use a tag routine for anything with a deadline you cannot miss, since the failure is silent and arrives without warning.

Tell anyone else affected what it does, so they can work around it rather than being confused by it.

And accept that a routine will break eventually. Designing for that is cheaper than being surprised by it.