Cấu hình repository

Tổ chức repository test theo mẫu User Journey hoặc Feature Test.

Nhiều team chọn cách tiếp cận monorepo, đặt bộ test Maestro cùng chỗ với mã nguồn app. Chiến lược này có một số lợi thế kỹ thuật:

• Đồng bộ phiên bản: test luôn gắn với phiên bản codebase mà chúng kiểm tra, đảm bảo các commit cũ vẫn tương thích với test
• Thay đổi nguyên tử: feature branch có thể gộp thay đổi logic app và cập nhật test tương ứng trong một pull request

Các mẫu cấu trúc repository

Một repo có cấu trúc tốt giúp bộ test dễ bảo trì khi app lớn lên. Phần lớn project được tổ chức theo một trong hai chiến lược cốt lõi:

Chiến lược	User Journeys (hướng mục tiêu)	Feature Tests (hướng thói quen)
Mục tiêu chính	Hoàn thành funnel	Giảm ma sát
Phù hợp nhất với	Thương mại điện tử, Fintech, Giao đồ ăn	Mạng xã hội, Nội dung, Giải trí
Động cơ người dùng	Hoàn thành một tác vụ cụ thể (ví dụ: đặt đồ ăn)	Tương tác và khám phá liên tục
Thước đo thành công	Đi đến cuối funnel	Tương tác không có ma sát

Chọn đúng cấu trúc giúp tự động hóa của bạn luôn phù hợp khi app lớn lên.

User journeys (app hướng mục tiêu)

Cách này phù hợp nhất với app thương mại điện tử, giao đồ ăn hoặc fintech (ví dụ DoorDash, Uber, ngân hàng). Các app này tồn tại để giúp người dùng hoàn thành một tác vụ cụ thể. Khi đói, người dùng mở app để đặt đồ ăn, ăn xong là thôi dùng.

• Mục tiêu: thành công được định nghĩa là người dùng đi đến cuối funnel (ví dụ: Đã xác nhận đơn hàng).
• Chiến lược: tổ chức repo theo hành trình. Tập trung vào các flow end-to-end theo dõi các biến thể của tác vụ chính (ví dụ: giao hàng so với tự đến lấy, áp dụng coupon, hoặc cổng thanh toán bên ngoài).

Mẫu này thường chia bộ test theo phân khúc người dùng (mới so với hiện có) và ngữ cảnh thực thi.

├── flows
│   ├── config.yaml
│   ├── tests
│   │   ├── 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>

Ghi chú triển khai kỹ thuật

Để tổ chức project thành cấu trúc phân cấp, bạn phải khai báo đường dẫn tìm kiếm trong config.yaml bằng key flows. Ví dụ, đặt flows: tests/** báo cho Astra Scout tìm mọi file flow trong thư mục con đó theo cú pháp glob. Cách này cho phép kiểm soát chi tiết test nào được chạy khi chạy cục bộ.

Feature tests (app hướng thói quen)

Cách này phù hợp nhất với app mạng xã hội, tổng hợp nội dung hoặc giải trí (ví dụ Reddit, Instagram, Spotify). Các app này thành công khi giảm ma sát và giữ người dùng gắn bó. Thành công là trải nghiệm tích lũy từ nhiều tương tác nhỏ mượt mà.

• Mục tiêu: thành công được định nghĩa là severity gắn bó cao và không có ma sát.
• Chiến lược: tổ chức repo theo từng tính năng. Bạn cần độ phủ sâu cho các thành phần vì chỉ một spinner chậm hay một tương tác fail cũng có thể khiến người dùng rời đi.

Tổ chức theo tính năng tạo ra sự tương ứng cấu trúc (ánh xạ trực tiếp) giữa bộ test và các module của app:

├── 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>