Magic principles in test automation: Time Lapse

testing magic automation
Reading time: 2 minutes, 44 seconds

In this article of the "Magic principles in test automation" series, I will talk about the concept of time lapse which is the key to powerful misdirection.

Time Lapse in Magic

"Time lapse" can mean multiple things. In magic, the most common understanding is the passing of time between two states or events.

Imagine a classic effect in which the following happens:

  • Phase 1: The magician shows a silver coin in his left hand and a copper one in his right.
  • Phase 2: He closes his fists.
  • Phase 3: When he opens them, the coins have switched places.

There are multiple ways in which time lapse can strengthen or weaken this seemingly simple chain of events:

Phase 1:

  • If the time for the initial showing of the coins is too short, the outcome of the effect might not be registered by the audience since they did not have time to grasp the initial state.
  • However, if the initial showing is too long, there is the possibility for the spectators to get bored before something has even happened.

Phase 2:

  • Closing the hands very quickly arises suspicion. Even if it is not technically possible to do a secret move here, it feels like it. This weakens the effect.
  • Closing the hands too slowly can be perceived as condescending and turn this effect into a "catch me if you can" challenge instead of a magic effect.

Phase 3:

  • Opening the hands very quickly does not give the spectators enough suspense. Instead, the effect happens so quickly that it even go by unregistered.
  • Opening the hands very slow, even one after the other, actually has a positive effect here. It ensures that the effect is perceived correctly and gives the feeling that something magical is happening.

Time Lapse in Software

When I started thinking about timing and the passing of time between two states of a system, two examples that popped into my mind were reporting and monitoring.

Timing of Reporting and Monitoring

For monitoring and test reporting to be relevant, this needs to happen as closely to a failing test or application state as possible. Otherwise both might be outdated already when too much time passes between the incident and the notification.

Like in magic, there must also be enough time to register the failed state and compare it to the previous state before the next run happens (and potentially overwrites and overrides it).

If both conditions are not met, it results in no meaning.

Timing is important!

Shifting left

In order to improve test feedback, more and more "shifting left" is happening. That means that tests are moved closer to the software development lifecycle phase where they can provide quicker and more meaningful information in case of failure. It is closely related to the "test early, test often" and "fail fast, learn fast" mindset.

This technique only makes sense, though, if the feedback and communication channels are fast enough to provide real-time notification and insight into failures to not fall into the traps mentioned above.


Let me close with a great Albert Einstein quote that fits perfectly here:

The only reason for time is so that everything doesn’t happen at once.

Previous Post Next Post