Writing Clear Instructions

To get the most out of tapioka.ai, instructions should be written in a simple, precise, and unambiguous way. Think of it as writing for someone who has never seen your application before.

Core Rules

1. Start from the Beginning

Every instruction is assumed to start from the app's initial state (e.g., the Home Screen after a fresh launch).

2. Writing Preconditions

If you want to change the initial state your test starts with, use Preconditions.

  • Purpose: Preconditions allow you to set up a specific state (like being logged in) before the main test instructions begin.

  • Default State: Without a precondition, the AI will always start execution from a very fresh app launch.

  • Efficiency: Using preconditions avoids repeating setup steps across multiple test cases.

  • Don't: Write multiple tests that repeat the same initial steps: "Login with these credentials, navigate to the profile page..."

  • Do: Use Preconditions to handle common setup logic. In this example, your main test can then start directly from the user profile.

3. Ensure Repeatability

Instructions should not modify the application or backend state in a way that causes future runs to fail. Your tests should always be able to run again on a "clean" environment.

  • Don't: "Add the the movie to favorites." If the item is already a favorite from a previous run, the test might fail to find the "Add" button.
  • Do: "Add the movie to favorites, then remove it from favorites." Alternatively, you can use Post-conditions (coming soon) to automatically revert the app state to its default after each run.

4. Functional over Technical

Describe what to do, not how to do it technically. Avoid describing UI elements like "checkboxes" or "divs" unless the AI fails to understand a simpler command.

  • Good: "...then accept the terms and conditions."
  • Avoid: "...then click the 'accept' checkbox next to the terms and conditions."

5. No Logic Branches

Instructions should be a straight path. Do not use "if/else" or branches (e.g., "Go to X and if the user is logged in, do Y"). Note: This rule does not apply to Preconditions. Precontions allows usage of branches

Examples

  • Standard Flow:
    • Scenario: "Go to Your Account, then Settings, and finally show the list of devices."
    • Expected Result: "A list containing at least one device should be displayed."
  • Search Flow:
    • Scenario: "Go to the search bar, search for 'Game of Thrones', and open the series page."
    • Expected Result: "The series details page for 'Game of Thrones' is shown with a summary of the episodes."
  • TV/Media Flow:
    • Scenario: "Go to TV, then view the TV Program."
    • Expected Result: "The TV schedule for the current day is visible."
  • File & OS Interaction:
    • Scenario: "Download any file from the 'Invoices and other documents' section. Minimize the app, open the device's File Manager, go to the 'Downloads' folder, and open the most recently downloaded document."
    • Expected Result: "The downloaded invoice or document is successfully opened and its content is displayed."
  • Form Submission:
    • Scenario: "Go to Your Account, then Settings, then 'Report a bug'. Click the empty text field under the email title and enter 'test@test'. Click next and enter the subject 'Test_topic'. Click next again and enter the message 'test_message'. Finally, hide the keyboard, tap send, and finish."
    • Expected Result: "The bug report is submitted successfully, and a confirmation message or a return to the settings screen is visible."