Skip to main content

Capture a step's correct behavior with step tests

Understand how to use step tests in Tines 3B.

Written by Jamie Gaynor

As you build a workflow, you confirm that each step does what you expect, then move on. Step tests let you capture the moment when a step is working as expected. A step test records a real input to a step and the output it produced, so you can replay it and check if the step still behaves the same way after you’ve made changes to your workflow.

What a step test is

A step test is a saved pair of files that live with the step:

  • one file holds the input the step received

  • the other holds the output it produced

When the test runs, Tines 3B feeds the saved input through the step's real command and compares what the step prints to the saved output. If they match, the test passes. If they differ, it fails and shows you exactly what changed.

Note: Each step can have as many step tests as you like.

A few useful details about how they run:

  • They don't touch anything live. Step tests run with no internet access, so they never call a real service or cause real-world side effects like sending a message.

  • They reuse the original responses. Tines 3B saves the responses from external requests the first time, and replays those, so the step sees the same answers every time instead of calling out to a live service.

  • They give the same result every time. The step runs as if it were still the moment you captured it, so even a step that uses the current time or a random value produces a comparable result.

  • They have a size limit. A test's input and output must each stay under 256 KB.

Why you'd use them

Step tests are built for the way building actually goes: you get a step working, then keep editing the workflow around it. Without tests, there's nothing to tell you when a later change breaks an earlier step. With step tests, you get that signal automatically.

Use step tests when:

  • You want to confirm a step's logic works correctly before deploying changes.

  • You're refactoring code and need to verify behavior stays the same.

  • You've fixed a bug and want to prevent it from returning.

  • You're building a step others will use and want to document expected behavior.

How to add a step test

You add a step test from a run you've already confirmed is right. The usual flow is:

  1. Open the step and run it (a solo run works well).

  2. On the run's Output view, check if the output is what you want.

  3. Select 'Add run as step test' (the microscope icon).

Tines 3B only creates a test from a successful run of that step, so if there's no good run yet, it will ask you to run the step first. From then on, that input and output are the baseline the step is measured against.

How step tests run and what the results mean

Step tests run on their own when you ask the assistant to replay them, and they also run automatically while Tines 3B builds and before you push a workflow live, so failures surface before they reach a live workflow. Each test ends in one of a few states:

  • Passed. The step produced the saved output.

  • Failed. The output differed, the step exited with an error, or a recorded request diverged. You get a message, plus the expected and actual output so you can see the difference.

  • Running. The test is still in progress.

  • Not run. There's no current result for this test yet.

Those step statuses then roll up again in the workflow's Tests panel, part of the workflow monitor tab, which shows at a glance how many of your steps are passing, failing, or not checked, and lets you re-run them all with one button.

What happens to results when you edit a step

A passing result only means something if it reflects the step as it is now, so Tines 3B ties every result to the exact version of the step that produced it:

  • Edit the step's code, and its results reset. Because the saved result no longer matches the current step, every test for that step shows as ‘not run’ until you run them again. This stops a stale "passed" from hiding a change you just made.

  • Edit a test's own input or output, and only that test resets. A test is only as fresh as the run it points to, so changing what a test checks invalidates just that test, not its neighbors.

This is why a step you haven't touched can keep showing passed while one you just edited asks to be run again.

Did this answer your question?