Organizing Tests

Quadrastack gives you flexibility in how you organize your tests.

Important Rule: You can only pass one playbook directory to the CLI at a time (e.g., quadrastack --playbook-dir ./tests). All YAML files found in that directory (and its subdirectories) will be loaded and merged into a single test plan.

Choose the structure that best fits your team's workflow:

Option 1: Single File (Simple Projects)

Perfect for prototypes, small APIs, or when you're just getting started. Define everything in one place.

Structure:

my-tests/
└── playbook.yaml

playbook.yaml:

vars:
  default:
    baseUrl: http://localhost:8080

requests:
  health-check:
    method: GET
    url: /health

workflows:
  smoke:
    steps:
      - request: health-check

Option 2: Group by Playbook Type (Recommended)

Ideal for most projects. Split your definitions by their type (requests, workflows, vars, etc.) to keep files manageable.

Structure:

my-tests/
├── requests.yaml      # All your API requests
├── workflows.yaml     # Your test flows
├── scenarios.yaml     # Test runners and configs
├── vars.yaml          # Environment variables
└── mocks.yaml         # Mock server definitions

Example:

requests.yaml:

requests:
  get-user:
    method: GET
    url: /users/1

workflows.yaml:

workflows:
  user-flow:
    steps:
      - request: get-user

Option 3: Group by Projects (Large Scale)

Best for large organizations, microservices, or mono-repos. Group files by feature or service to allow multiple teams to work independently.

Structure:

my-tests/
├── shared/
│   ├── vars.yaml              # Shared config
│   └── setup.yaml             # Common setup workflows
├── auth-service/
│   ├── requests.yaml          # Auth-specific requests
│   └── workflows.yaml         # Auth-specific workflows
├── payment-service/
│   ├── requests.yaml
│   └── workflows.yaml
└── user-service/
    ├── requests.yaml
    └── workflows.yaml

How it works: When you run quadrastack --playbook-dir ./my-tests, the CLI recursively finds all YAML files in shared, auth-service, etc., and combines them.

• Naming Collision: Ensure workflow and request names are unique across folders (e.g., auth-login instead of just login) to avoid conflicts.

---

Which one should I choose?

Option	Best For	Pros	Cons
#1 Single File	Learning, Prototypes	Easiest to read	Gets messy fast
#2 By Type	Most Teams	Clear separation	Can be hard to find feature-specific code
#3 By Project	Enterprise, Microservices	Modular, Scalable	Requires naming discipline