# Testing

**Analysis Date:** 2026-05-05

## Framework

None. No PHPUnit, no Jest, no Vitest. No automated test runner configured.

**Only testing mechanism:** Two manual PHP scripts in the project root, run in-browser while logged in as admin against the live database.

## Test Files

| File | Type | Purpose |
|------|------|---------|
| `test-yacht-plugin.php` | Smoke test | Verifies plugin environment is set up correctly |
| `test-api-availability.php` | Integration test | Exercises REST endpoint + Availability class |

**How to run:**
```
# Syntax check (run after every PHP edit):
php -l wp-content/plugins/yacht-booking-system/includes/class-booking.php

# Browser smoke test (must be logged in as admin):
http://jachty.pagedev.local/test-yacht-plugin.php

# Browser integration test:
http://jachty.pagedev.local/test-api-availability.php
```

## What Is Tested

### test-yacht-plugin.php (Smoke Test)
1. Plugin file exists on disk
2. Plugin is active (`is_plugin_active()`)
3. `wp_yacht_availability` table exists
4. CPTs registered (`yacht`, `yacht_booking`)
5. Plugin options set (`yacht_booking_version`, `yacht_booking_installed_at`)
6. Custom capabilities assigned to `administrator` role
7. REST namespace `yacht-booking/v1` registered + route list
8. Admin menu `yacht-bookings` slug present
9. Yacht CPT CRUD: `wp_insert_post()` + meta + `wp_delete_post()` (cleanup included)

### test-api-availability.php (Integration Test)
1. Fetch first yacht from DB
2. Call `/availability/{yacht_id}` via `wp_remote_get()` — check HTTP 200, count statuses
3. Direct call `Availability::get_availability_calendar()` — display in HTML table
4. Direct call `Availability::is_available()` on +7 to +10 day range
5. `mark_as_booked()` with fake booking ID 999 → re-check → `clear_booking_availability(999)` → re-check (full CRUD cycle)

## What Is NOT Tested

- `POST /bookings` — full booking creation flow via REST never tested
- Email sending (`send_booking_notification`, `send_customer_notification`, `Inquiry::send_emails`)
- Google Calendar OAuth flow
- GCal sync (push and pull)
- iCal import and export
- Admin form processing (`process_yacht_save`, `process_booking_actions`, `save_settings`)
- Nonce verification in REST endpoints
- Status transitions (`pending` → `confirmed` → `cancelled`) and side effects
- `Shortcode::render_calendar()` output
- `Calendar_Widget::render()` output
- All JavaScript behavior
- Concurrent booking race conditions
- `mark_as_available()` bug (deletes all rows for yacht — see concerns.md)

## Test Pattern

```php
// Access guard
require_once __DIR__ . '/wp-load.php';
if (!current_user_can('manage_options')) { die('Admin only'); }

// Numbered HTML sections
echo '<h2>1. Section Name</h2>';

// Visual pass/fail — no assertions that throw
if ($condition) {
    echo '✅ Thing works<br>';
} else {
    echo '❌ Thing broken<br>';
    die(); // hard stop only on fatal blockers
}

// Data output
echo '<details><summary>Raw data</summary><pre>';
print_r($data);
echo '</pre></details>';
```

## Mocking

None. All tests hit the live WordPress database. Side effects are real:
- `test-yacht-plugin.php`: creates and deletes a test yacht post
- `test-api-availability.php`: inserts availability rows with `booking_id=999`, then deletes them

## Coverage Tooling

None. No coverage measurement.

## Style Notes in Test Files

Intentional deviations from plugin code conventions (acceptable for dev-only scripts):
- Short array syntax `[]` used (plugin uses `array()`)
- No namespaces
- Partial output escaping — `$yacht->post_title` sometimes raw-echoed
- One raw `$wpdb->get_var()` without `prepare()` (`test-yacht-plugin.php:49`) — safe here as table name is not user input