Test/add initial smoke tests

[adidev001]

Summary

This PR adds an initial automated smoke test setup for reactome-mcp.

The main thing I wanted to do here was add a lightweight way to catch breakage in the MCP surface without relying on manual Inspector testing or live Reactome service calls every time. To make that possible, I pulled server construction into a small shared factory that can be used both by the runtime entrypoint and by tests.

Included in this PR

• added src/server.ts so the MCP server can be created in tests without starting stdio
• updated src/index.ts to use the shared server construction path
• added a separate TypeScript config for tests
• added build:test / test scripts
• ignored dist-test/
• added a small smoke test suite using node:test

Current test coverage

The suite currently checks:

• server initialization

• representative tool/resource/template registration

• mocked smoke tests for:

  • reactome_search
  • reactome_get_pathway
  • reactome_get_analysis_result

• invalid blank query/token cases

• representative static and templated resource handling

Notes

The tests stub the content and analysis client boundaries so they stay fast and deterministic.

I also tightened validation a bit for blank search queries and analysis tokens, mainly so those failure cases are clearer and easier to cover in tests.

Verified

• npm run build
• npm test

[adamjohnwright]

Thank you for this — and apologies it sat for so long.

The repository has moved since March: it now uses vitest with a tests/ directory and a fake-server helper, so the node:test runner, tsconfig.test.json and dist-test/ build here are superseded by what landed in the meantime. But two ideas in this PR are good ones, and they are taken in #28 with credit to you:

The server factory. createServer() is exactly right, and for a reason beyond testability: a hosted deployment has to serve Streamable HTTP from the same registrations and needs one server per session, and neither is possible while the only instance is constructed at module scope. It also means importing the entrypoint no longer starts a server. This unblocked a design question we had open — it is written up in specs/002-transport-and-hosting.

The trimmed, shared argument schemas. Rejecting blank and whitespace-only values at the schema is the right call: an empty q reaches the Content Service as either an error or a request for everything, and an empty analysis token produces a 404 that reads like the analysis expired. This is now nonEmptyString in src/schemas.ts, shared by 76 argument schemas across every tool module, keeping the 2048-character cap that was added later.

Your server-registration tests are adapted into tests/server.test.ts, including one that asserts the graph tools stay absent while NEO4J_URI is unset — a boundary we care about enough that it is now a constitutional principle.

Closing in favour of #28, with the credit recorded in the commit message and the changelog rather than lost. Sorry again for the delay, and thank you for the contribution.

[adamjohnwright]

Correction to the count above: it is 83 argument schemas across the tool modules, not 76.

[adamjohnwright]

Closing as harvested — the detail is in my earlier comment.

Both ideas are on main now via #28, credited to @adidev001 in the commit message, the PR, and the changelog (#30):

• createServer() — src/server.ts. It also unblocked a design question we had open; written up in specs/002-transport-and-hosting.
• Trimmed, shared argument schemas — nonEmptyString in src/schemas.ts, now used by 83 argument schemas across every tool module.

Your server-registration tests are adapted into tests/server.test.ts, including one asserting the graph tools stay absent while NEO4J_URI is unset.

Thank you, and sorry again that it sat so long.