---
title: "Testing Shield in CI & Local Dev"
description: "Fixed test sitekeys and secrets that behave deterministically — run your test suite against Shield with no real keys, no network state, and no analytics pollution."
url: https://edge.network/docs/shield/testing/
---

# Testing Shield in CI & Local Dev

Shield

# Testing & CI

Shield ships fixed test keys with deterministic behaviour, so your test suite never
needs real credentials, never depends on scoring outcomes, and never pollutes your
widget's analytics. They work on any hostname.

## Test Sitekeys (Client Side)

Use these in place of your real sitekey to force a specific widget behaviour:

| Sitekey | Behaviour |
| `es_test_pass` | Always verifies — the widget shows the normal success state and produces a token |
| `es_test_block` | Every solve fails — exercise your error handling and no-token paths |
| `es_test_interactive` | Background attempts always escalate to the "I am human" confirmation first |

```
<!-- In your test/staging environment -->
<div class="edge-shield" data-sitekey="es_test_pass"></div>
```

## Test Secrets (Server Side)

Use these in place of your real secret to force a specific siteverify response,
regardless of the token you send:

| Secret | siteverify response |
| `es_secret_test_pass` | `success: true`, score 90 |
| `es_secret_test_fail` | `success: false` with `invalid-input-response` |
| `es_secret_test_spent` | `success: false` with `timeout-or-duplicate` — the replayed-token path |

```
# Always succeeds, score 90
curl -X POST https://shield.edge.network/siteverify \
  -d "secret=es_secret_test_pass" \
  -d "response=anything"

{
  "success": true,
  "score": 90,
  "challenge_ts": "…",
  "hostname": "localhost",
  "error-codes": []
}
```

## What Test Traffic Can and Can't Do

- Test keys work on any hostname, including `localhost`, with no widget configuration.
- Test challenges use trivial proof-of-work, so CI runs stay fast.
- Test traffic records no analytics and no scoring signals — it cannot skew your real widgets' metrics or the network's scoring.
- Tokens minted by test sitekeys are dummy strings that only test secrets accept — a real secret will never validate one, and vice versa.

**Never ship test keys to production.** `es_secret_test_pass`
accepts anything — a form "protected" by it is protected by nothing. Keep test keys in
test configuration only, exactly as you would a mock.

## Next Steps

[Getting Started Protect your first form in five minutes](https://edge.network/docs/shield/getting-started) [Server-Side Validation The siteverify API and humanity score](https://edge.network/docs/shield/siteverify)
[Back to Docs](https://edge.network/docs) [Need help?](https://edge.network/support)