Skip to main content

​
Testing

Use the public endpoint for connection and read-only discovery checks. A complete submission test requires an explicit Hum test arrangement because create_order can reach fulfillment.
Do not place a production order with invented data. Hum does not publish deterministic test addresses, reusable test credentials, or a self-service transactional sandbox. If Hum provides a review arrangement, use only its designated address, customer data, expected outcome, and cleanup procedure.

​
Public connection smoke test

Connect a generic MCP client to:
No API key is required. Record the client name and version, negotiated MCP protocol version, server name and version, endpoint, and test time. Verify:
  1. Initialization succeeds over Streamable HTTP.
  2. tools/list returns exactly check_availability, validate_order, create_order, and get_order with closed input schemas and the documented side-effect annotations.
  3. The server card reports the same endpoint, identity, and version.
  4. skills/list and skills/get expose both public skills.
  5. resources/read returns the exact canonical bytes for:
    • skill://check-internet-availability/SKILL.md
    • skill://order-internet-service/SKILL.md
You can compare the HTTP skill responses with those resources: Their byte counts and SHA-256 digests must match the corresponding skill discovery entries.

​
Contract and fixture checks

The released contract contains the exact public schemas and runtime input combinations. The scenario file contains synthetic responses approved for documentation and client development. For each documented request:
  1. Validate the arguments against the released tool input schema.
  2. Check the argument keys against the tool’s accepted runtime shapes.
  3. Confirm unknown keys are rejected.
For each documented response:
  1. Match it to a named scenario and its release provenance.
  2. Validate it against the released output schema.
  3. Confirm the page does not add fields or stronger claims than the fixture supports.
The fixtures demonstrate shapes and client behavior. They do not guarantee that a public address will produce a particular provider, offer, question, price, timing, or fulfillment result.

​
Availability exercises

With approved test data or the released fixtures, exercise:
  • ambiguous address selection
  • a missing unit
  • FCC findings while the live source is still checking
  • FCC-only, live-only, and both-source matches
  • live completion, failure, and timeout
  • a current typed question set and its continuation
  • informational catalog plans with no executable offer
  • at least one executable offer with an exact offer ID
  • an expired or stale continuation
  • rate limiting and a retry delay
Verify that the client preserves partial results, labels FCC findings as area evidence, waits before polling, sends no stale question answer, and never presents a catalog plan as orderable.

​
Validation exercises

With an executable fixture or approved environment:
  • start validation from an exact lookup and offer
  • collect only the returned required fields
  • correct field-specific errors
  • reject a stale revision
  • poll a checking draft
  • handle a changed, unavailable, or expired offer
  • reach a ready review
Confirm that validation creates no order and sends no fulfillment request. The client must present the exact returned review and keep unknown facts unknown.

​
Submission and recovery exercises

Run these only under Hum’s explicit transactional test arrangement:
  • authorization for the exact current review and terms hash
  • one queued submission with a stable idempotency key
  • an identical replay that resolves to the same intended order
  • an idempotency conflict with changed input
  • a lost or interrupted create response followed by get_order
  • recorded accepted, rejected, unknown, and not-submitted outcomes when the arrangement supports them
The client must retrieve before retrying after an uncertain create call. It must not describe any fulfillment state as ISP acceptance or installation confirmation.

​
Test with and without the skill

Run the supported workflow twice through a generic MCP client:
  1. Load skill://order-internet-service/SKILL.md before beginning.
  2. Start a new client context and rely only on server instructions, tool descriptions, schemas, and tool results.
Record whether each client correctly handled clarification, partial evidence, executable offers, non-committing validation, exact-review authorization, retrieval-first recovery, and fulfillment status language.

​
Internal mocked tests

Hum’s repository tests cover schema validation, result rendering, skill and metadata parity, and mocked workflow states. These tests are release checks for Hum’s implementation. They are not a public sandbox, do not prove that a provider will return the same result, and do not authorize a live fulfillment submission. Contact support@letshum.com for an approved end-to-end review arrangement.