# Integration Testing
The integration test suite validates the full MCP server chain end-to-end against a live RemNote instance. Unlike the
unit tests (which mock the WebSocket bridge), these tests send real MCP tool calls through the running server to RemNote
and verify the responses.
## Prerequisites
1. RemNote running with the RemNote Automation Bridge plugin installed and connected
2. MCP server running (`npm run dev` or `npm start`)
3. Plugin connected to the WebSocket server (check server logs for connection message)
## Running
```bash
# Interactive — prompts before creating content
npm run test:integration
# Non-interactive — skips confirmation
npm run test:integration -- --yes
# Fast connection check only (no test data creation)
./run-status-check.sh
```
## Configuration
| Variable | Default | Purpose |
|---|---|---|
| `REMNOTE_MCP_URL` | `http://127.0.0.1:3001` | MCP server base URL |
| `MCP_TEST_DELAY` | `2000` | Delay (ms) after creating notes before searching |
## What It Tests
The suite runs five sequential workflows:
1. **Status Check** — Verifies the server reports a connected plugin. If this fails, all subsequent workflows are
skipped since there's no point testing tools without a live connection.
2. **Create & Search** — Creates two notes (simple and rich with content/tags), waits for RemNote indexing, then
validates both `remnote_search` and `remnote_search_by_tag` across `includeContent` modes (`markdown`,
`structured`, `none`).
3. **Read & Update** — Reads the created notes, updates title/content/tags, and re-reads to verify persistence.
4. **Journal** — Appends entries to today's daily document with and without timestamps.
5. **Error Cases** — Sends invalid inputs (nonexistent IDs, missing required fields) and verifies the server handles
them gracefully.
## Test Artifacts
All test content is prefixed with `[MCP-TEST]` followed by a unique run ID (ISO timestamp), and is created under the
shared root-level anchor note `RemNote Automation Bridge [temporary integration test data]`.
Anchor resolution is deterministic:
1. multi-query `remnote_search` lookup + exact title match (trim/whitespace normalized),
2. fallback `remnote_search_by_tag` lookup using the dedicated anchor tag `remnote-integration-root-anchor`,
3. create anchor note only if both lookups fail.
When reusing a title-only hit, integration setup backfills the anchor tag for future deterministic lookup.
Uniqueness is enforced: if more than one exact anchor-title match exists, the integration run fails immediately and
prints duplicate `remId`s so you can clean up test data in RemNote.
RemNote's bridge plugin does not support deleting notes, so test artifacts persist and must be cleaned up manually.
To clean up: search your RemNote knowledge base for `[MCP-TEST]` and delete the matching notes.
## Design Rationale
The integration tests are deliberately separate from the unit test suite. They require external infrastructure (running
server + connected plugin), create real content, and take seconds rather than milliseconds. They run via `tsx` with
custom lightweight assertions — no vitest dependency — to keep them independent of the mocked test environment.
