Optics Docs
GitHub

Choose how to create tests

Learn which way of creating tests fits your team. Every way produces the same files.

View as Markdown

Optics gives you several ways to turn a user flow into a test. They all end in the same plain-text suite: CSV or YAML files that live in your repository and run with optics execute. You can mix them in one project, so a test someone recorded can sit next to one an AI agent wrote.

Each way of creating a test writes the same suite, which runs the same way on every build.

Choose your approach#

Write itNo codeList the steps in a spreadsheet or text editor. Anyone can read and review them.Record itNo codeRun steps one at a time against the live app in optics live. What works is saved.Describe itAIType what you want in plain English. An AI model drives the app and keeps the steps.Delegate itAIConnect your AI agent with optics mcp. It explores the app and writes the suite.Code it in PythonCodeCall keywords from pytest or any Python script.Code it in Robot FrameworkCodeUse Optics keywords in .robot files.

Which one should I use?#

We recommend recording for most people starting out. You see each step work on the real app before it's saved, and you end up with readable CSV files you can edit by hand later. Teams then usually write small changes directly in the files.

Choose describe or delegate when you have a Gemini API key or an AI agent, and want a first draft of a long flow quickly. Review what the AI saved, the same way you'd review a colleague's change.

Choose Python or Robot Framework only if your tests need logic that the files can't express, or your team already runs everything through pytest or Robot. Code-based tests lose the main benefit of Optics files: that anyone on the team can read them.

WriteRecordDescribeDelegatePython / Robot
Best forSmall edits, reviewsBuilding a flow on the real appLong flows, quick draftsAgent-driven teamsCustom logic
You needAn editorA running appA Gemini API keyAn MCP clientPython skills
OutputCSV or YAMLCSVCSVCSVPython or .robot
Runs withoptics executeoptics executeoptics executeoptics executepytest or robot
EffortNo codeNo codeNo codeNo codeCode

Every way ends in plain text#

Tests are files in your repository, not records in someone else's cloud. That has two practical benefits:

  • Changing a test is a pull request. When a redesign moves the sign-in button, the diff shows the one element that changed.
  • CI runs exactly what was merged. There's no separate test-management system to keep in sync.
test_data/elements.csv
 Element_Name,Element_ID
 email_field,//*[@resource-id='email']
-sign_in,//*[@text='Sign in']
+sign_in,//*[@resource-id='login']
+sign_in,Sign in
 search_bar,//*[@resource-id='search']

See also#