LogoLogo
🚀 Run Maestro tests in the cloud →
  • Home
  • Star us on GitHub
  • Getting Started
    • What is Maestro?
    • Installing Maestro
      • macOS
      • Windows
      • Linux
    • Build and Install your App
      • Android
      • iOS
    • Run a Sample Flow
    • Writing Your First Flow
    • Maestro Studio
    • Running Flows on CI
  • Cloud
    • Run Maestro tests in the cloud
    • Cloud Quickstart
    • CI Integration
      • GitHub Actions
        • Maestro GitHub Action for Android
        • Maestro GitHub Action for iOS
        • Maestro GitHub Action for Flutter
      • Bitrise
      • Bitbucket Pipelines
      • CircleCI
      • Integration with any CI platform
    • Pull Request Integration
    • Cloud Reference
      • Build your app for the cloud
      • Configuring OS Version
      • Configuring device locale
      • Device timezones
      • Email Notifications
      • Slack Notifications
      • Webhook Integration
      • Managing Secrets
      • Limits
      • Reusing App Binary
      • IP Allowlist
      • System Status
  • Platform Support
    • Supported Platforms
    • Android - Views
    • Android - Jetpack Compose
    • iOS - UIKit
    • iOS - SwiftUI
    • React Native
    • Flutter
    • Web Views
    • Web (Desktop Browser)
  • Examples
    • Android contacts flow automation
    • Facebook signup flow automation
    • Advanced: Wikipedia Android
    • Page Object Model
  • CLI
    • Cloud
    • Test Suites & Reports
    • Tags
    • Record Your Flow
    • Continuous Mode
    • View Hierarchy
    • Start Device
  • API Reference
    • Commands
      • addMedia
      • assertVisible
      • assertNotVisible
      • assertTrue
      • assertWithAI
      • assertNoDefectsWithAi
      • back
      • clearKeychain
      • clearState
      • copyTextFrom
      • evalScript
      • eraseText
      • extendedWaitUntil
      • extractTextWithAI
      • hideKeyboard
      • inputText
      • killApp
      • launchApp
      • openLink
      • pressKey
      • pasteText
      • repeat
      • retry
      • runFlow
      • runScript
      • scroll
      • scrollUntilVisible
      • setAirplaneMode
      • setLocation
      • startRecording
      • stopApp
      • stopRecording
      • swipe
      • takeScreenshot
      • toggleAirplaneMode
      • tapOn
      • doubleTapOn
      • longPressOn
      • travel
      • waitForAnimationToEnd
    • Common command arguments
    • Selectors
    • Configuration
      • Workspace configuration
      • Flow configuration
      • AI configuration
  • Advanced
    • Nested Flows
    • Wait
    • Loops
    • Conditions
    • Parameters & Constants
    • JavaScript
      • Run JavaScript
      • Outputs
      • Logging
      • Access element text
      • Make HTTP requests
      • GraalJS support
      • JavaScript announcement blog
    • Specify a Device
    • Configure Permissions
    • Detect Maestro in your app
    • Configure Maestro driver timeout
    • onFlowStart / onFlowComplete hooks
    • Test in different locales
    • Structuring your test suite
  • Troubleshooting
    • Known Issues
    • Frequently Asked Questions
    • Bug Report
    • Rollback Maestro
    • Debug Output
    • HOWTOs
      • Arrange your repository for Maestro tests
      • scrollUntilVisible for fragments
  • Community
    • Contributions
    • Articles & Tutorials
    • Case Studies
    • Resources
Powered by GitBook

Read to wire into CI or scale up your testing?

  • Run Maestro tests in the cloud →
On this page
  • Journeys
  • Features

Was this helpful?

Edit on GitHub
  1. Troubleshooting
  2. HOWTOs

Arrange your repository for Maestro tests

PreviousHOWTOsNextscrollUntilVisible for fragments

Last updated 27 days ago

Was this helpful?

Lots of teams choose to keep their Maestro tests alongside the code for their application. That way, a build from a few months back that now needs a patch also has the correct version of the tests sat with them, and a new feature branch that changes how login works can have the changes to the test flows developed right alongside.

But what's a good way to lay this out?

Boring tester answer: it depends

Journeys

If you arrange your tests as journeys through your application, then you likely want some top-level folder to contain them, and only start organising them into deeper subfolders once they become unwieldy. Maybe you end up with something like this:

├── flows
│   ├── config.yaml
│   ├── login.yaml
│   ├── register.yaml
│   └── shopping.yaml
└── src
    └── app
        └── <code here>

Which later spreads into something deeper, once you decide to start splitting. Here, I've broken this up between flows centered around new and existing users, and an extra folder to contain utility scripts that might be shared.

├── flows
│   └── config.yaml
│       ├── new_users
│       │   ├── register.yaml
│       │   └── shopping_first_time_discount.yaml
│       ├── existing_users
│       │   ├── account_settings.yaml
│       │   ├── deeplink_from_email.yaml
│       │   ├── deeplink_from_notification.yaml
│       │   ├── login.yaml
│       │   ├── shopping.yaml
│       │   └── shopping_bulk_buy_discount.yaml
│       └── utils
│           └── set_discount_code.js
└── src
    └── app
        └── <code here>

Features

For testing approaches that are centered on validating the behaviours of individual features or requirements, you might choose to mirror the source structure, so that the tests are easy to find and maintain:

├── flows
│   └── config.yaml
│       ├── account
│       │   └── set_display_name.yaml
│       ├── auth
│       │   ├── login.yaml
│       │   ├── login_invalid.yaml
│       │   └── login_locked_account.yaml
│       ├── basket
│       │   ├── add_to_cart.yaml
│       │   └── update_cart.yaml
│       └── checkout
│           ├── complete_purchase.yaml
│           └── save_for_later.yaml
└── src
    └── app
        ├── account
        │   └── <code here>
        ├── auth
        │   └── <code here>
        ├── basket
        │   └── <code here>
        └── checkout
            └── <code here>
😄