> ## Documentation Index
> Fetch the complete documentation index at: https://docs.memorose.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing

> How to run tests and understand the current test structure in Memorose.

# Testing

## Running tests

Run the full Rust test suite:

```bash theme={null}
cargo test
```

Or test individual crates:

```bash theme={null}
cargo test -p memorose-core
cargo test -p memorose-server
cargo test -p memorose-gateway
cargo test -p memorose-common
```

Run a specific test by name:

```bash theme={null}
cargo test -p memorose-core test_ingest_and_retrieve
```

## Test organization

### Unit tests

Most unit tests are co-located with the modules they exercise via `#[cfg(test)]` blocks.

Common places to inspect:

* `crates/memorose-core/src/engine/tests.rs`
* module-local `#[cfg(test)]` blocks in `graph/`, `llm/`, `raft/`, `worker.rs`, and dashboard handlers

### Integration tests

Current integration tests live in:

* `crates/memorose-core/tests/integration.rs`

These cover end-to-end ingest and retrieval flows.

## Common patterns

### Async tests

I/O-heavy tests typically use `#[tokio::test]`.

### Temporary directories

Tests that need isolated storage usually build engines against temp directories rather than shared repo state.

### Mocking external calls

HTTP-bound tests use `wiremock` in several places, for example in:

* `crates/memorose-server/src/shard_manager.rs`
* `crates/memorose-core/src/llm/openai_tests.rs`
* `crates/memorose-core/src/llm/gemini_tests.rs`

### LLM behavior in tests

There is no current runtime switch in `AppConfig` like `[development].use_mock_llm` that the server loader consumes. In practice, tests use explicit mock client implementations inside Rust test code.

## Writing new tests

* Put unit tests close to the code they exercise.
* Put cross-module integration tests under `crates/memorose-core/tests/`.
* Prefer descriptive names such as `test_hybrid_search_with_agent_filter`.
* Prefer temp directories over shared on-disk paths.
* Avoid real provider calls unless you are explicitly validating provider integration.

## Dashboard checks

For the Next.js dashboard, the currently available scripts are:

```bash theme={null}
cd dashboard
pnpm lint
pnpm build
```

If you need local interactive verification:

```bash theme={null}
pnpm dev
```