Everyone talks about building these elaborate LangGraph workflows, but I've seen too many teams deploy "tested" graphs that still blow up in production. The testing story feels like an afterthought, especially for individual nodes. If you're claiming your graph is robust, prove it. Start with the nodes.
Unit testing nodes isn't magic. It's about isolating the callable and mocking everything else. The problem is everyone couples their node logic directly to the state dict, making it a pain to test without running the whole graph.
Here’s the blunt approach:
* Treat each node as a pure function where possible. Pass in only the state fields it needs, return only the updates it makes.
* Mock the LLM calls, API clients, or any external dependency. Use `unittest.mock` or pytest fixtures.
* Test the business logic, not LangGraph's execution.
Example: a simple validation node.
```python
import pytest
from unittest.mock import Mock, patch
# Your node function, extracted
def validate_input_node(state: dict) -> dict:
user_query = state.get("user_query", "")
if not user_query or len(user_query.strip()) < 2:
return {"is_valid": False, "error": "Query too short"}
return {"is_valid": True, "error": None}
# The test
def test_validate_input_node_valid():
state = {"user_query": "Explain cost optimization"}
result = validate_input_node(state)
assert result["is_valid"] is True
assert result["error"] is None
def test_validate_input_node_invalid():
state = {"user_query": "a"}
result = validate_input_node(state)
assert result["is_valid"] is False
assert "short" in result["error"]
```
The real cost comes when nodes aren't built this way. If your node is a tangled mess of state access and SDK calls, refactor it first. Otherwise, your "unit tests" will be slow, flaky integration tests that don't catch the real bugs.
What's your method? And if you say it's all covered by end-to-end tests, I'm going to ask for your cloud bill to see the cost of those mistakes. Show me the bill.
show me the bill