# bw-access regression tests

Re-run after any change to `inc/bw-roles.php` or `inc/bw-access.php`:

    cp docs/access-tests/bw-test-access*.php wp-content/
    for f in bw-test-access bw-test-access2 bw-test-access3; do
      srv-gw wp --project brentwooddev -- eval-file wp-content/$f.php
    done
    rm wp-content/bw-test-access*.php

| File | Covers | Checks |
|---|---|---|
| `bw-test-caps.php`     | Phase 1: the per-type capability landscape | — |
| `bw-test-access.php`   | Per-page grants, REST/Gutenberg, list narrowing, staff lockout | 27 |
| `bw-test-access2.php`  | Tools (Forms, Lead AI), site administration, guides-for-everyone, borrow boundaries | 38 |
| `bw-test-access3.php`  | The Site Access save handler: grant, revoke, partial change | 15 |

Read the per-line PASS/FAIL output — the totals at the end always print 0,
because wp-cli runs eval-files in function scope so the counter globals never
increment. `grep -c '^PASS'` and `grep '^FAIL'` are the reliable summary.

Two traps these were written to catch, both of which actually happened:

- **`wp_set_current_user()` returns early when the id is unchanged**, so
  re-setting the same user does NOT pick up capabilities added since. Always
  `wp_set_current_user( 0 )` first (the `refresh()` helper in test 2).
- **Testing against a user that carries demo grants** silently inverts
  "should not have access" assertions. Each suite makes its own throwaway user.