Testing Policy Document Demo 3 - COS301-SE-2026/Mealchemy GitHub Wiki

• Introduction
• Testing Objectives
• Testing Scope
• Testing Levels and Types
• Testing Tools and Technologies
• Test Environment and Configuration
• Test Data Management
• Test Execution Procedure
• Defect Management
• Acceptance Criteria
• Roles and Responsibilities
• CI and Review Process
• Non-Functional Testing Policy
• Test Documentation and Reporting
• Policy Maintenance
• Testing Commands Reference

The Mealchemy testing policy defines the standards and procedures followed when testing the system throughout development. Its purpose is to ensure that new features are verified before they are merged, and that existing functionality is protected against regressions as the project grows.

Mealchemy consists of a Flutter frontend, a Spring Boot backend, a PostgreSQL database, and supporting services such as the recipe engine. The system is split across multiple layers, so testing is required at different levels. Unit tests are used to verify individual pieces of logic in isolation. Integration tests are used to confirm that controllers, services, repositories, the database, and API contracts work together correctly. Frontend tests are used to verify model mapping, repository behaviour, provider state management, and important UI interactions. End-to-end tests are used to validate complete user workflows against the real application environment.

This policy also supports the team’s development workflow by defining when tests should be written, how they should be run, and what must pass before a feature is considered ready. Testing is treated as a shared responsibility: each developer is expected to test the feature they are working on, keep test configuration local where needed, and ensure that automated checks pass before code is merged into the development branch.

The goal of this testing policy is not only to find defects, but also to improve confidence in the reliability, maintainability, and correctness of Mealchemy.

The main objective of testing in Mealchemy is to verify that the system behaves correctly, remains reliable after changes, and meets the functional and non-functional requirements. Testing is used throughout development to identify defects early and reduce regressions before code is merged.

The testing objectives for Mealchemy are to:

• Verify that individual units of code, such as services, repositories, models, and providers, behave as expected.
• Confirm that frontend features correctly communicate with backend API endpoints.
• Ensure that backend controllers, services, repositories, database migrations, and security configuration work together correctly.
• Validate that user-facing workflows, such as authentication, pantry management, shopping lists, recipes, and vault features, function correctly.
• Verify end-to-end user journeys using the real frontend, backend, database, and mobile test environment.
• Check that changes do not break existing functionality through regression testing.
• Support maintainability by encouraging clear, testable code.
• Ensure that automated tests and CI checks provide consistent quality feedback before pull requests are merged.
• Identify important non-functional concerns, including performance, usability, security, and reliability, where they affect the quality of the application.

Testing in Mealchemy is not treated as a final step after development, but as part of the development process itself. Each feature should be tested at the appropriate level based on its risk, complexity, and impact on the rest of the system.

The testing policy applies to all parts of the Mealchemy system. This includes the Flutter frontend, Spring Boot backend, PostgreSQL database interactions, API integrations, and supporting services used during development. Testing is required for new features, bug fixes, integration work, and changes that may affect existing behaviour.

The scope of testing includes:

• Frontend models, repositories, providers, screens, and important user interactions.
• Backend controllers, services, repositories, DTOs, security behaviour, and error handling.
• API communication between the Flutter frontend and Spring Boot backend.
• End-to-end workflows running against the real backend, PostgreSQL database, and Android emulator.
• Database-related behaviour, including repository queries and Flyway migrations.
• Authentication and protected routes where user-specific data is involved.
• Regression testing for features that may be affected by new changes.
• Non-functional concerns such as usability, security, performance, and maintainability where they are relevant to the feature being tested.

Testing does not require every feature to be tested in the same way. Smaller isolated changes may only need focused unit tests, while features that involve multiple layers, database access, authentication, or API integration require broader integration testing. This ensures that testing effort is proportional to the risk and complexity of the change.

Mealchemy uses different levels of testing to verify the system from small isolated units through to larger integrated workflows. The type of testing used depends on the feature being developed, the risk of the change, and the number of system layers involved.

Unit testing verifies individual pieces of logic in isolation. These tests should be fast, focused, and independent of external systems such as the database, network, or Docker containers.

In the backend, unit tests are used to test service-layer business logic with mocked dependencies. These tests usually use JUnit 5 and Mockito. In the frontend, unit tests are used for models, repositories with mocked API responses, and Riverpod providers where state changes can be tested without running the full app.

Integration testing verifies that multiple parts of the system work together correctly. In Mealchemy, this includes backend tests that load the Spring context, apply database migrations, use the real PostgreSQL database, and test controller behaviour through MockMvc.

Integration testing is especially important for features that involve API endpoints, authentication, database queries, or multiple backend layers. These tests help confirm that the controller, service, repository, DTOs, database schema, and security configuration work together as expected.

End-to-end testing verifies complete user journeys through the Mealchemy application using the real frontend, backend, PostgreSQL database, and Android emulator. These tests confirm that the system works from the user’s perspective, rather than only testing individual units or isolated integrations.

Mealchemy uses Maestro for E2E testing. Maestro flows are written as YAML files and are stored in the e2e/flows/ directory. These flows simulate real user interactions such as launching the app, entering text, tapping buttons, checking visible screen text, and completing key workflows.

E2E tests are used for critical user journeys, such as registration, login, pantry updates, vault actions, recipe workflows, and shopping list flows. E2E tests are slower and require more setup than unit or integration tests, therefore they are more focused on important workflows rather than every small edge case.

Local E2E testing requires Docker, the backend, PostgreSQL, an Android emulator, and the Flutter app running against the local backend URL. In CI, E2E tests are triggered manually because they are slower than regular pull request checks. When an E2E test fails, screenshots, logs, and Maestro reports should be used to diagnose the issue.

Frontend widget tests are used to verify that important screens and UI interactions behave correctly. These tests check that screens render expected content, validation messages appear when required, buttons trigger the correct actions, and provider state updates are reflected in the UI.

For Mealchemy, widget tests are particularly useful for screens such as pantry, vault, shopping lists, login, preferences, and recipe-related workflows.

API repository tests verify that frontend repositories call the correct backend endpoints, send the correct request bodies, and correctly map backend JSON responses into frontend models. These tests are usually kept offline by using mocked Dio responses instead of calling the real backend.

This is important because many Mealchemy features depend on backend integration. Repository tests help catch mismatches between frontend expectations and backend API contracts.

Nutritional calculator repository tests should verify the nested totals, per-serving values, and per-ingredient response structure returned by GET /api/nutritional-calculator/{recipeId}. Tests should cover integer and decimal numeric values, loading and retry behaviour, unavailable recipes, zero-calorie percentage calculations, and switching between per-recipe and per-serving presentation.

Offline testing verifies that previously synchronised content remains safely readable when the backend cannot be reached. Tests should cover cached recipes, vaults, discovery content, pantry items, and shopping lists.

Offline tests should verify that:

• Cached content remains available after connectivity is lost.
• Cache data is isolated by user and does not leak between accounts.
• Same-user re-authentication preserves the correct cache.
• Signing in as another user switches to the correct cache namespace.
• Partial or failed synchronisation does not destroy valid cached data.
• Cache freshness is tracked independently for each collection.
• Offline banners and freshness information are displayed correctly.
• Create, edit, delete, favourite, checkbox, bulk-selection, and pantry-update actions are disabled while offline.
• Central request protection prevents mutation requests while offline.
• Online functionality is restored after reconnection.

These tests should use mocked connectivity and storage dependencies where possible. Tests must not depend on physically disconnecting the developer’s machine unless performing manual acceptance testing.

External services such as USDA must not be called directly by unit, provider, repository, or widget tests. Tests should use mocked responses or adapter implementations so that they remain fast, repeatable, and independent of third-party availability or rate limits.

Tests for external ingredient data should cover:

• Successful catalogue fallback searches.
• Mapping external response fields into Mealchemy models.
• Importing a selected external ingredient into the local catalogue.
• Category-selection flows when an external ingredient has no mapped category.
• Missing or partial nutritional values.
• Invalid responses, timeouts, and external-service failures.

Regression testing ensures that existing functionality still works after changes are made. Whenever a bug is fixed or a feature is changed, relevant existing tests should be rerun. Automated CI checks also support regression testing by running tests before code is merged.

Non-functional testing focuses on qualities such as performance, usability, reliability, maintainability, portability, and security. These tests may not always be fully automated, but they should be considered when a feature affects user experience, system stability, authentication, protected data, or deployment behaviour.

In Mealchemy, non-functional testing includes checking that the app remains usable on supported screen sizes, API calls respond within acceptable time, protected endpoints require authentication, and the code remains maintainable through linting and review.

Mealchemy uses a combination of testing tools to support frontend, backend, integration, and quality assurance activities. These tools help the team test features consistently across different parts of the system.

For the Flutter frontend, the main tools are:

• flutter analyze for static analysis and linting.
• flutter test for model, repository, provider, and widget tests.
• Dio interceptors or mocked responses for testing API repository behaviour without calling the real backend.
• Riverpod ProviderContainer and provider overrides for testing state management in isolation.
• Maestro for end-to-end testing using YAML flows.
• Android Emulator for running E2E tests against a real mobile environment.
• e2e/flows/ for storing committed E2E user-flow tests.
• GitHub Actions manual workflow for running E2E tests in CI.

For the Spring Boot backend, the main tools are:

• JUnit 5 for writing and running automated backend tests.
• Mockito for mocking dependencies in service unit tests.
• Spring Boot Test for full-context backend integration tests.
• MockMvc for testing controller routes and HTTP request/response behaviour.
• Spring Security Test for testing secured endpoints and authenticated controller behaviour.
• Maven commands such as ./mvnw test, ./mvnw verify, and ./mvnw checkstyle:check.

For the local development and integration environment, the team uses:

• Docker Compose to run the backend, PostgreSQL database, and supporting services such as the engine.
• PostgreSQL for database-backed integration testing.
• Flyway migrations to keep the database schema consistent.
• Local environment files such as .env and application-test.properties for developer-specific configuration.

For continuous integration and code quality, the project uses:

• GitHub Actions to run automated checks on pull requests.
• Checkstyle for backend formatting and style rules.
• Test coverage tools, where applicable, to help identify untested areas.
• Security scanning tools such as Trivy where included in the CI pipeline.

These tools ensure that both local testing and pull request validation follow a consistent process across the team.

Mealchemy testing is performed in both local development environments and automated CI environments. Each environment must be configured consistently so that tests behave predictably and do not depend on one developer’s machine or personal database state.

For local development, the backend, PostgreSQL database, and supporting services are run using Docker Compose. This allows developers to test backend and integration behaviour against a controlled local environment. The frontend can be tested using Flutter’s testing tools and can be run against either mock repositories or the local backend API, depending on the feature being tested.

Backend integration tests require a test configuration file named application-test.properties. This file is stored locally in backend/src/test/resources/ and is not committed to Git because it contains developer-specific database credentials. Developers should create it from the provided example file and ensure that the database URL, username, password, and JWT configuration match their local .env setup.

Mock data may be used during frontend development and isolated testing, especially when a backend endpoint is incomplete or when the test should not depend on a running server. However, features that are being integrated with the backend must also be tested with mock data disabled, using the real API and local Docker environment.

The test environment should support:

• Running frontend tests without a live backend where possible.
• Running backend unit tests without a database.
• Running backend integration tests with PostgreSQL and Flyway migrations.
• Running API integration checks against the local backend.
• Keeping secrets, passwords, and machine-specific configuration out of Git.
• Ensuring that test results are repeatable for all developers.

This separation between mock testing, local integration testing, and CI testing helps the team identify whether failures are caused by frontend logic, backend logic, API contracts, database configuration, or environment setup.

Tests that access cached data, secure storage, connectivity state, or SQLite must isolate their storage and user identity. Tests must not read or overwrite a developer’s real device credentials or production cache. Provider overrides, temporary databases, mocked connectivity services, and in-memory or test-specific storage implementations should be used where available.

External API credentials, including USDA API keys, must remain in ignored local environment files or CI secrets. API keys must never be placed directly in source code, test fixtures, screenshots, documentation examples, or committed configuration files.

Test data in Mealchemy must be controlled, repeatable, and suitable for the type of test being performed. Tests should not depend on random data, personal developer data, or database records that may change unexpectedly.

For frontend unit and widget tests, mock data should be used where possible. Mock repositories and mocked API responses allow tests to run quickly and consistently without requiring Docker, PostgreSQL, or a live backend. This is especially useful for testing model mapping, provider state changes, screen rendering, form validation, and user interactions.

For backend unit tests, mocked dependencies should be used so that business logic can be tested independently of the database. These tests should define only the data needed for the specific behaviour being tested.

For backend integration tests, test data can be inserted into the local PostgreSQL database as part of the test setup. These tests should rely on known database state and should clean up or isolate data where necessary so that one test does not affect another. Flyway migrations should be used to ensure that the database schema is consistent before integration tests are run.

For manual integration testing, developers may use local test accounts and local database records. This data should not be treated as permanent or shared project data. If data needs to exist for all developers or deployed environments, it should be added through a migration or agreed setup process rather than manually inserted into one developer’s local database.

Sensitive information, such as database passwords, JWT secrets, and personal credentials, must not be committed to Git. Any required test configuration should be stored in ignored local files or documented through example files.

Testing should be performed throughout development and before code is submitted for review. Developers are responsible for running the tests that are relevant to the feature or fix they are working on, while CI provides an additional automated check before merging.

For frontend changes, developers should run static analysis and the relevant Flutter tests. The usual commands are:

• cd frontend
• flutter analyze
• flutter test

For smaller changes, developers may first run only the affected test file, such as a specific repository, provider, or screen test. Before opening or updating a pull request, the relevant test suite should be rerun to confirm that the feature still passes after all changes.

For backend changes, developers should run the appropriate Maven test command based on the type of change. Unit tests can be run without a database, while integration tests require the local PostgreSQL database and test configuration to be available.

• cd backend
• ./mvnw test
• ./mvnw verify
• ./mvnw checkstyle:check

E2E tests are run separately from normal unit and integration tests because they require the full application environment. To run E2E tests locally, the developer must start the backend and PostgreSQL services with Docker Compose, confirm that the backend health endpoint returns UP, start an Android emulator, run the Flutter app against the local backend URL, and then execute the relevant Maestro flow.

Example command:

• maestro test e2e/flows/auth-register.yaml

E2E tests should only be committed once the flow is complete and passing. Empty or unfinished YAML files should not be committed because Maestro attempts to parse all flow files and this can break the E2E test run.

When backend integration tests are required, Docker Compose should be used to start the required local services:

• docker compose -f infrastructure/docker-compose.yml --env-file .env --profile engine up --build

Before a pull request is considered ready for review, the developer should confirm that:

• The relevant frontend or backend tests pass locally.
• Static analysis or linting passes.
• The feature has been manually checked if it affects user-facing behaviour.
• Mock data and real API behaviour have both been considered where applicable.
• No local secrets or environment-specific files have been committed.
• CI checks pass on the pull request.

This procedure helps ensure that issues are caught early and that code submitted for review is stable, tested, and ready to be evaluated.

Defects found during testing must be recorded, investigated, fixed, and retested before the related feature is considered complete. A defect may be identified through unit tests, integration tests, frontend tests, E2E tests, manual testing, code review, CI failures, or user feedback during development.

When a defect is found, the developer should first identify where the issue occurs. For example, the problem may be caused by frontend state management, incorrect API response mapping, backend validation, database configuration, authentication, routing, environment setup, or an incomplete endpoint. Once the cause is understood, the fix should be made on the relevant feature or bug-fix branch.

After a defect is fixed, the developer must rerun the relevant tests to confirm that the issue has been resolved. If the defect reveals missing test coverage, a new test should be added where appropriate so that the same issue is less likely to return in future changes. For E2E failures, developers should also inspect the Maestro screenshots, logs, and failure reports to determine which part of the workflow failed.

Defects should be handled according to their severity:

• Critical: Prevents the application from running, blocks login, breaks core workflows, corrupts data, or causes serious security issues.
• High: Breaks an important feature, API integration, or user workflow, but does not affect the entire system.
• Medium: Causes incorrect behaviour in a smaller feature or edge case.
• Low: Minor visual, wording, usability, or non-blocking issues.

Pull requests should not be merged while they contain known critical or high-severity defects. Medium and low-severity defects may be scheduled for follow-up only if they do not block the feature’s acceptance criteria.

A feature or fix is considered ready for review when it has been implemented, tested, and verified against the relevant requirements. The required level of testing depends on the complexity and risk of the change.

Before a pull request is submitted, the developer should confirm that:

• The feature meets the functional requirement or issue description.
• Relevant unit tests have been added or updated.
• Relevant frontend repository, provider, or widget tests have been added or updated.
• Relevant backend unit or integration tests have been added or updated where backend behaviour is affected.
• E2E testing has been considered for important user workflows.
• flutter analyze passes for frontend changes.
• Relevant flutter test commands pass for frontend changes.
• Relevant Maven test or verification commands pass for backend changes.
• API integration has been manually checked when the feature depends on backend communication.
• Mock data and real API behaviour have both been considered where applicable.
• Loading, empty, error, retry, and offline states have been tested where relevant.
• API tests use mocked responses and do not consume external service quotas.
• Cached data and provider state are isolated between tests.
• User-specific cache isolation has been tested when offline functionality is affected.
• Unit and nutrition values are rendered according to the backend contract without duplicating server-side calculations.
• User-facing changes have been checked on a supported target device or emulator.
• No local configuration files, secrets, passwords, or generated environment files have been committed.
• The code has been pushed to the correct feature branch.
• CI checks pass on the pull request.
• The pull request has been reviewed and approved according to the workflow.

For high-risk features, such as authentication, database updates, pantry updates, shopping list completion, or recipe and vault workflows, broader testing is required. This may include backend integration tests, frontend provider tests, API repository tests, manual testing against Docker, and E2E validation using Maestro.

A feature should not be merged into the development branch if it fails required automated checks, contains unresolved critical or high-severity defects, or has not been reviewed.

Testing is a shared responsibility across the Mealchemy team. Each developer is responsible for testing the code they write and ensuring that their changes do not break existing functionality.

Developers are responsible for:

• Writing or updating tests for the features and fixes they implement.
• Running the relevant local test commands before opening or updating a pull request.
• Checking that frontend analysis, backend linting, and relevant automated tests pass.
• Testing API integration locally when their feature communicates with the backend.
• Keeping local configuration files, secrets, and environment-specific test files out of Git.
• Fixing defects found during local testing, CI, E2E testing, or code review.

Reviewers are responsible for:

• Checking that the pull request meets the feature requirements.
• Reviewing whether the submitted tests are appropriate for the scope of the change.
• Identifying missing test coverage, unclear test data, or possible regressions.
• Confirming that CI checks pass before approving the pull request.
• Requesting follow-up changes where defects or testing gaps are found.

The team is responsible for:

• Maintaining shared testing standards and updating them when the project changes.
• Agreeing on which workflows require E2E testing.
• Keeping test commands, setup instructions, and environment requirements documented.
• Ensuring that testing remains practical, consistent, and useful throughout development.
• Reviewing recurring defects to identify areas where better tests or clearer implementation patterns are needed.

This shared responsibility helps ensure that quality is built into the development process instead of being handled only at the end.

Continuous integration is used to provide automated feedback before changes are merged into the development branch. CI checks help confirm that the code compiles, follows project standards, and passes the required automated tests.

When a pull request is opened or updated, the relevant GitHub Actions workflows should run automatically. These checks may include frontend analysis, frontend tests, backend unit tests, backend integration tests, backend Checkstyle linting, build verification, and security scanning. A pull request should not be merged if required CI checks are failing.

The review process should include both code review and testing review. Reviewers should check that the implementation is correct, follows the project structure, and includes appropriate tests for the feature. They should also check that no local configuration files, secrets, test credentials, generated files, or unrelated changes have been committed.

E2E tests are handled separately because they are slower and require a full application environment. Maestro E2E tests can be run locally by developers and may also be run through the manual GitHub Actions workflow. E2E testing should be used for important workflows where the team needs confidence that the frontend, backend, database, authentication, and mobile environment work together correctly.

If a CI check fails, the developer responsible for the pull request should inspect the failure logs, reproduce the problem locally where possible, fix the issue, rerun the relevant tests, and push the correction. If the failure is caused by an environment or pipeline problem rather than the feature itself, this should be communicated clearly in the pull request.

A pull request is ready to merge only when the implementation has been reviewed, the required tests pass, the test coverage is above 80%, the relevant CI checks are successful, and any blocking review comments have been resolved.

Non-functional testing focuses on qualities that affect how well the system works. In Mealchemy, non-functional testing is considered throughout development because it affects the user experience, system reliability, maintainability, and security of the application.

The main non-functional areas considered are:

• Usability: Screens should be clear, readable, and easy to use on supported devices. Important workflows such as login, pantry management, recipe discovery, vault usage, and shopping list management should be understandable and efficient for users.
• Performance: The application should respond within a reasonable time during normal use. API calls, loading states, database queries, and large UI lists should be checked where they may affect user experience.
• Reliability: Features should handle loading states, empty states, errors, failed requests, and invalid input without crashing.
• Security: Protected endpoints should require authentication, JWT tokens should be handled correctly, and sensitive information such as passwords, secrets, and local configuration values must not be committed to Git.
• Maintainability: Code should follow the project structure, use clear naming, avoid unnecessary duplication, and include tests where behaviour may be affected by future changes.
• Portability: The application should work in the supported development and testing environments, including local Flutter development, Docker-based backend services, Android emulator testing, and CI.
• Offline resilience: Cached content should remain readable during network loss, and failed synchronization must not corrupt previously valid cached data.
• Data isolation: Cached content, secure credentials, and user-specific state must not be exposed to another signed-in user.
• External-service resilience: USDA failures, missing data, timeouts, and rate limits should produce controlled behaviour rather than crashes.
• Accessibility: Important controls should have readable labels, adequate contrast, suitable touch targets, and meaningful semantics where practical.
• Responsive layout: Important screens should be manually or automatically checked at supported mobile sizes to detect overflow and inaccessible content.

Non-functional testing may be performed through automated tests, manual checks, code review, CI workflows, E2E tests, and security scanning. The depth of non-functional testing depends on the risk of the feature.

Testing activities should be documented clearly enough for other team members to understand what was tested, how it was tested, and whether the feature is ready for review. This documentation does not need to be excessive, but it should make the testing status of a feature visible.

For each pull request, the developer should include a short testing summary. This may include the commands that were run, the test files that were added or updated, any manual testing that was performed, and if a feature was tested against the real backend, Docker, PostgreSQL, or an Android emulator.

Backend pull requests should mention whether unit tests, integration tests, Checkstyle, or Maven verification commands were run. If integration tests require local configuration such as application-test.properties, the developer should confirm that the file was used locally and not committed.

E2E test results should be documented when a Maestro flow is added, changed, or manually executed. If an E2E test fails, developers should use the generated screenshots, logs, and Maestro reports to help identify the cause. Relevant findings should be noted in the pull request or issue.

Defects should be reported with enough detail to reproduce the issue. A useful defect report should include:

• A description of the problem.
• Steps to reproduce the issue.
• Expected behaviour.
• Actual behaviour.
• Screenshots, logs, or error messages.
• The environment where the issue occurred, such as local backend, emulator, or CI.

The testing policy should be reviewed and updated as Mealchemy grows. As new features, tools, workflows, and CI checks are added, the policy should be adjusted so that it continues to reflect the team’s actual development process.

The team should update the testing policy when:

• A new testing tool or framework is introduced.
• A new CI workflow or required check is added.
• The backend, frontend, database, or deployment architecture changes.
• New E2E flows are added for important user journeys.
• The team agrees on new testing standards or naming conventions.
• Repeated defects show that the current testing approach is missing an important risk.
• Setup instructions for local testing change.

Policy maintenance is a shared responsibility. Developers should raise updates when they notice that the documented process no longer matches the real workflow. Reviewers should also check whether testing expectations remain clear and practical during pull request reviews.

The goal of maintaining the policy is to keep testing consistent, useful, and realistic for the team. The policy should support development instead of becoming outdated documentation that no longer reflects how the project is tested.

• flutter pub get
• flutter analyze
• flutter test
• flutter test --coverage

To run a specific frontend test file:

• flutter test test/features//<test_file>.dart

• ./mvnw test
• ./mvnw verify
• ./mvnw checkstyle:check

To run backend unit tests only:

• ./mvnw test -Dtest="*UnitTest" -DfailIfNoTests=true

To run backend integration tests only:

• ./mvnw test -Dtest="*IntegrationTest" -DfailIfNoTests=true

• docker compose -f infrastructure/docker-compose.yml --env-file .env up -d --build
• docker compose -f infrastructure/docker-compose.yml --env-file .env down
• docker compose -f infrastructure/docker-compose.yml --env-file .env down -v

• cd frontend
• flutter run -d android --dart-define=BACKEND_URL=http://10.0.2.2:8080

After the app appears on the emulator, stop Flutter with q, then run:

• cd ..
• maestro test e2e/flows/auth-register.yaml

To run all Maestro flows:

• maestro test e2e/flows/