How to test an Android macro step by step without deleting actions

When an Android macro fails halfway through a sequence, repeating the entire flow does not always reveal the cause. The tap may be correct while its preceding condition fails. A swipe may work by itself but reach the wrong screen after another step. Deleting actions to shorten the test only creates work when you need to rebuild them.

EmuloMobile provides two separate controls for investigating this kind of failure: Test runs one step once on the current screen, while the power control temporarily disables a top-level step. You can check an action in isolation, remove sections from the next full trial, and keep their configuration in the builder.

This guide covers debugging an existing macro. To build your first flow, start with the guide to Android automation without a PC, ADB, or root.

Start with the first observable difference

Before editing the macro, reproduce the failure once and record the first difference between the expected and actual result. Do not begin with the last symptom.

Suppose the macro should open a list, choose an item, and confirm it. A missing confirmation may have started earlier: the list did not open, the wrong item was tapped, or the final button condition did not pass. The first divergent screen narrows the section you need to inspect.

Record three points:

1. which screen should be visible before the step;
2. which action or condition should respond to that screen;
3. which change should appear immediately afterward.

This reference separates a failure in the current step from a failure inherited from the previous one.

Understand the difference between testing and disabling

The two controls are not interchangeable.

Testing a step answers: “Does this card work now, with the screen in this state?” EmuloMobile evaluates the conditions attached to the step and, if they pass, triggers the action once on the real screen.

Disabling a step answers: “How does the rest of the macro behave without this card during a run?” The execution engine skips a disabled step before evaluating its conditions and before performing any screen capture or OCR that it requires. Neighboring steps keep their order.

An individual test confirms local behavior. A run with temporarily disabled steps confirms the interaction among a smaller set of actions. Use the two levels in that order.

Prepare the screen for an individual test

Open the target app and leave it in the exact state the step expects. An isolated test does not automatically perform all the setup that would normally happen before it.

Check the macro prerequisites as well:

• use the resolution and orientation saved when the macro was created;
• enable the EmuloMobile accessibility service for tap and gesture actions;
• allow screen capture when the step or its conditions depend on image, color, or text;
• stop another run before requesting a new builder capture;
• use test data if the action can confirm, submit, or delete something in the target app.

If the step depends on a variable changed earlier, reproduce that setup in the flow or adjust the test case. Variables start with their defaults in a new session; the guide to variables and counters in Android macros explains that lifecycle.

How to test one step in EmuloMobile

Open the automation in the builder and find the first card related to the divergence. Then:

1. place the target app on the screen expected by the step;
2. return to the builder without changing the resolution or orientation;
3. tap the green Play icon on the card to test the step;
4. observe whether the conditions pass and the action fires;
5. immediately return to the target app and check the expected change.

Make only one adjustment per trial. If an image tap does not find its target, for example, first check the reference and search region. Adjust the match settings afterward. Changing the region, condition, and timing together makes it impossible to know which correction fixed the failure.

When a step works alone but fails in the flow

This result shows that the action can work, but it does not prove that the action receives the correct state during the sequence. Check:

• whether the previous step produced the expected screen;
• whether the interface needs time to finish a transition;
• whether the condition is evaluated before its visual signal appears;
• whether a variable still has the expected value;
• whether another step changes the same screen area before the action.

The problem is now at the boundary between steps, not necessarily inside the tested card.

Disable steps without deleting them

Use the power control on top-level cards to reduce the full run. A disabled card appears dimmed in the builder. Its index is preserved, and the configured action remains available for reactivation.

A controlled procedure is:

1. keep the required setup steps enabled;
2. disable cards that come after the section under investigation;
3. select Save, because builder changes are explicit;
4. prepare execution and run the reduced section;
5. find the first incorrect change;
6. re-enable one step at a time until the failure returns.

Do not use deletion as a debugging shortcut. Deleting a step removes its configuration and may remove images owned by it when the change is saved. Disabling preserves the card and its parameters.

Account for compound actions

Only top-level cards can be enabled or disabled individually. Sub-actions inside a Compound Action do not show a separate power control.

When you disable a top-level Compound Action, treat the entire block as excluded from the trial. To investigate a particular child, use the test control on that sub-action card or create a controlled copy of the macro with a smaller structure. Do not assume every child works because the complete block passed once.

This boundary preserves the block as a unit: the parent condition and internal sequence usually represent one decision in the flow.

Example: isolate a failure after confirmation

Consider a macro with five steps:

1. tap Open;
2. swipe a list;
3. tap an item by text;
4. tap Confirm when the correct title is visible;
5. take a screenshot of the completed screen.

The screenshot does not appear. Start by placing the app on the confirmation screen and test step 5. If the image is saved, the final action works in that state.

Next, test step 4 on the screen before confirmation. If it works alone, temporarily disable steps 1 and 2, place the app on the list manually, and run steps 3, 4, and 5. If the problem returns, inspect the boundary between item selection and confirmation. If it does not, re-enable steps 1 and 2 one at a time.

The goal is not to prove that every card works on any screen. It is to find the smallest set that still reproduces the failure.

Interpret the result without losing context

An isolated test can create false confidence when the manually prepared context differs from the actual run. Before accepting a fix, compare:

• the test screen with the screen produced by the previous step;
• variable defaults with values accumulated during the flow;
• dialogs, keyboards, or overlays that change the layout;
• the action order inside compound blocks;
• the card conditions, which are always evaluated before the action.

After the reduced test, run at least one complete sequence from the beginning. Use the EmuloMobile floating controls to pause as soon as an unexpected screen appears without losing the point you need to inspect.

Checklist before treating the macro as ready

After debugging:

• re-enable every step that belongs in the final flow;
• make sure no required card remains dimmed;
• explicitly save the automation;
• run it once from its real initial state;
• test a condition that should not pass as well;
• verify pause and stop behavior;
• use the same resolution and orientation chosen during creation.

A stable macro is not merely a collection of steps that work alone. The screen produced by each step must be the screen expected by the next one.

Find the failure before rebuilding the flow

Testing one step and temporarily disabling cards turns a long sequence into smaller hypotheses. Confirm local behavior first, reduce the complete run next, and then restore steps in order. This method preserves configured actions and makes it clear where the screen state stops matching the plan.

Explore EmuloMobile to build, test, and run macros directly on Android.