Best practices

There are three key things to keep in mind when authoring a test in Semaloop:

Give the agent context, not assumptions. The agent can only act on what it can see or what you tell it. “Log in with a premium account” means nothing to the agent unless you also give it a way to get there, a secret, a seeded test account, or a setup step that puts the account in that state before the test runs.
Describe the goal, not the taps. Say what the user’s trying to do and what should be true after. Keep the data (amounts, names, quantities), since that’s what defines a successful outcome, but drop button names, tap order, and screen names.
Check something durable. Anchor to what stays on screen (an item in a list, an updated value), not spinners, toasts, or banners that vanish.

Following these principles you can avoid writing a poorly written test like this:

Click the ‘Log in’ button then sign in with email ‘newuser@test.com’ and password ‘Password123’. If sign in shows “Success,” go to Settings > Delete account. Check you can see “Welcome to my app,” then click ‘Sign up,’ and enter ‘newuser@test.com’ and password ‘Password123.’ Tap the first product thumbnail on the home screen, tap “Add to Basket,” tap the basket icon in the top right, tap “Checkout,” tap “Confirm Payment,” and check the toast says “Order placed!”

Instead, you can write an excellent test that withstands all the UI shifts your application can throw at it:

Reset the test account, then complete sign up with the newly reset account. Add the first item in the catalogue to the basket, and complete checkout. Verify the order confirmation screen shows the correct item and total.

Semaloop also allows you to test non-deterministic flows, like the output from an agent, where you can assert on an outcome rather than exact wording. For example:

Open the assistant and ask “what’s my account balance?” Verify the response is relevant, includes a specific number and doesn’t say the account couldn’t be found.