To test a LangGraph agent without calling real tools, give the graph a fixed starting state, control the model response, and provide a mock tool result at the graph boundary. Then assert the observable state transitions and final output. This checks the graph behavior represented by those inputs; it does not prove that a live model will make the same decision or that a real service will work.
Choose which behavior the test should prove
LangGraph is a low-level framework for building stateful workflows and agents. Its graphs can combine predictable, hand-coded steps with agentic steps, so a test can focus on orchestration without asking a live model to make decisions. The LangGraph overview demonstrates a graph with a mock LLM node, compilation, and invocation using a fixed user message.
As an Amazon Associate I earn from qualifying purchases.
Before writing a test, identify the specific graph behavior you want to check:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Initial state: Does the graph receive the expected messages or other state fields?
- Routing: Given a controlled result, does execution take the intended path?
- State updates: Do nodes add or change the expected values?
- Tool-call handling: Does the graph continue appropriately when a known tool result is present?
- Final state: Does invocation produce the expected messages or other observable output?
Keep these assertions separate from claims about agent decision quality. A test that supplies a predetermined model response can verify how the graph handles that response, not whether a live model would choose it.
Fix the graph input and control the model
Build the smallest graph that contains the behavior under test, compile it, and invoke it with a known input. For example, use a fixed user message and a predictable model response so that the test is repeatable. This is a test-design application of the mock-LLM pattern shown in the official overview, rather than a universal LangGraph pytest recipe.
When testing control flow, make the controlled model output exercise a meaningful branch: for example, a response that continues normally or one that requests a tool. The point is to hold the decision constant while checking what the graph does next. Avoid relying on a live model in a test whose purpose is to prove routing or state handling; variable output makes it harder to tell whether a failure is in orchestration or model behavior.
Supply a mock tool result instead of performing the action
For a test of how the graph handles a tool result, provide a controlled result in graph state rather than executing the external action. LangGraph’s human-in-the-loop guide describes adding a mock tool result as messages in state and reviewing or modifying tool calls before continuing. This pattern can exercise downstream handling without making the real call on that test path.
Keep the mock result aligned with the shape your graph expects, and make its content distinctive enough to trace through subsequent state updates. A mock can show whether the graph consumes and propagates a supplied result; it cannot establish that a live service will return that shape, succeed, or be available.
Assert only what the graph exposes
After invocation, check the returned state and other observable behavior available in your implementation. Useful assertions can cover the final messages, changed state fields, or whether a particular route or tool-execution path was taken, if the graph exposes that information. These checks should correspond directly to the controlled input and mock response.
LangGraph’s cited documentation supports the general patterns of graph execution and tool-call handling, but it does not establish one universal assertion API or a complete current Python pytest fixture-and-patching recipe. Use the invocation and state interfaces available in the versions installed in your project; do not treat an example written for another dependency version as a guaranteed drop-in test.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use integration tests for live dependencies
Controlled graph tests and live integration tests answer different questions. A small, separately identified integration test is appropriate when you need to check credentials, network access, an external service’s actual schema or availability, or live model behavior. Keep that coverage distinct from deterministic tests so failures identify whether the problem lies in graph orchestration or in a live dependency.
| Test level | Determinism | External dependencies | What it can reveal |
|---|---|---|---|
| Controlled graph test | Repeatable to the extent inputs, model responses, and tool results are fixed | Can avoid live model and tool calls in the tested path | State flow, routing, and handling of the supplied responses and results |
| Live integration test | Depends on live model and service behavior | Uses the credentials, network, and services under test | Failures involving live behavior, access, connectivity, or actual service responses |
The cited documentation does not publish quantitative speed or cost comparisons between these test levels. Choose them by the behavior you need to establish, rather than assuming a particular performance advantage.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
