# TANRAIL ONE — Testing & Quality Strategy

## 1. Objective
Ensure that the TANRAIL ONE platform remains stable as new businesses and modules are added over time. Strict testing is required to prevent data leakage between Business Units and ensure financial accuracy.

## 2. Test Categories

### 2.1 Unit Tests
- **Focus:** Individual methods, calculations, and service classes.
- **Examples:** 
  - `CalculateTaxAction` returns the correct amount.
  - `InventoryValuationService` computes average cost correctly.

### 2.2 Feature / Integration Tests (Crucial)
- **Focus:** End-to-end workflows and API endpoints.
- **Examples:**
  - `OrderFulfillmentTest`: Verifies that confirming an order successfully decreases inventory and creates an invoice.

### 2.3 Authorization & Scoping Tests (CRITICAL)
- **Focus:** Preventing cross-BU data leakage.
- **Mandatory Tests:**
  - `RestaurantManagerCannotViewCateringInvoicesTest`
  - `CashierCannotVoidInvoiceTest`
  - `GlobalScopeEnforcesBUIsolationTest`: Ensures that a query for `Product::all()` only returns products for the logged-in user's active BU context.

## 3. Definition of "Done"
A feature is NOT considered done until:
1. It meets the Acceptance Criteria in the Functional Requirements (Doc 05).
2. Happy-path Feature Tests are written and passing.
3. Authorization failure tests are written and passing (e.g., verifying a 403 Forbidden is returned for unauthorized access).
4. Code is peer-reviewed (or AI-agent reviewed against architectural guidelines).
5. The UI conforms to the UX guidelines (Doc 09).

## 4. Regression Testing
- As the system grows, the automated test suite must run via CI/CD before any merge to the `main` branch.
- This guarantees that modifying a Core component (like Invoicing) for a new "Water" business does not accidentally break the existing "Restaurant" invoicing process.