# Test Validator

> Test an existing Juju charm integration validator against a deployed charm. Use when asked to test, verify, or run an existing validator.

- Skill: `canonical/test-validator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add canonical/test-validator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/canonical/test-validator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: canonical (https://skillmd.com/u/canonical)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/canonical/test-validator

---


# Task: test an existing validator

## Goal

Deploy a minimal charm bundle that exercises the target validator and confirm
it passes at the requested level. Report any failures with diagnostic detail.

## Steps

1. Identify which validator to test from `validators/<name>/pyproject.toml`
   (look at `[project.entry-points."endpoint_validators"]` for the interface name).

2. Write `/tmp/spec.yaml` with a minimal two-charm deployment that creates
   a relation on that interface. Use a dedicated model name like `<interface>-test`.

3. Create the model, generate, and deploy the bundle:
   ```
   juju add-model <interface>-test
   bundle-builder-x --spec /tmp/spec.yaml --output-bundles /tmp/bundles/
   juju deploy /tmp/bundles/<interface>-test.yaml -m <interface>-test
   juju wait-for application <provider> -m <interface>-test --timeout 10m
   juju wait-for application <requirer> -m <interface>-test --timeout 10m
   ```

4. Run the validator at the **highest level the validator supports** (check
   `validate()` in `validator.py` -- use `deep` if implemented, otherwise `simple`):
   ```
   $PROJECT_ROOT/development-sandbox/bin/dev-validate.py \
     --model <interface>-test \
     --app <requirer> \
     --level <highest-supported-level>
   ```

5. Run automated verification evidence:
   ```
   $PROJECT_ROOT/development-sandbox/bin/verify-validator.sh \
     --model <interface>-test \
     --app <requirer> \
     --provider <provider> \
     --validator <name> \
     --level <highest-supported-level> \
     --output-dir $PROJECT_ROOT/development-sandbox/reports/<name>-$(date +%Y%m%d-%H%M%S)
   ```
   If the backend is a raw Kubernetes deployment (not a Juju app — e.g. MinIO for `s3`),
   the default `juju scale-application` down step won't break connectivity because the
   Juju databag retains credentials even at 0 units. In that case use `--down-cmd` and
   `--restore-cmd` to scale the k8s deployment directly:
   ```
   $PROJECT_ROOT/development-sandbox/bin/verify-validator.sh \
     --model <interface>-test \
     --app <requirer> \
     --provider <provider> \
     --validator <name> \
     --level <highest-supported-level> \
     --output-dir $PROJECT_ROOT/development-sandbox/reports/<name>-$(date +%Y%m%d-%H%M%S) \
     --down-cmd "sudo k8s kubectl scale deployment <backend> -n <interface>-test --replicas=0 && sleep 5" \
     --restore-cmd "sudo k8s kubectl scale deployment <backend> -n <interface>-test --replicas=1 && sleep 15"
   ```
   This must capture workload-up and workload-down behavior. The report persists on
   the host at `development-sandbox/reports/`.

6. Report results. If any check fails:
   - Show the full JSON output.
   - Show `juju debug-log` output if relevant.
   - Describe what the failure indicates about the validator or the charm.
   - Do NOT modify validator code unless instructed. If you are asked to fix the
     validator, follow the patterns and notes in the `/develop-validator` skill.

7. Clean up:
   ```
   juju destroy-model <interface>-test --destroy-storage --no-prompt
   ```

## Output

Summarize:
- PASS / FAIL / ERROR for each check
- Workload-up and workload-down evidence (from `verify-validator.sh` summary/report)
- Whether the failure is in the validator logic or the charm's databag
- Any suggested fixes (but do not apply them unless asked)