What are query depth and complexity limits, and why test them?

GraphQL's flexibility is also a denial-of-service surface. A client can write:

query {
  user { friends { friends { friends { friends { ... } } } } }
}

Each level multiplies the work. Without limits, one request can exhaust the server. Hardened GraphQL APIs apply:

• Depth limiting — reject queries nested beyond N levels.
• Complexity/cost analysis — assign each field a cost and reject queries above a budget.
• Rate limiting / pagination caps — bound first: 100000 style requests.

What to test:

1. Negative: send an over-deep or over-complex query and assert it's rejected (with an appropriate error/code), not executed.
2. Boundary: a query at the documented limit succeeds; one step over fails.
3. Positive: ensure legitimate, reasonably-nested queries aren't caught by an over-aggressive limit (a false-positive that breaks real clients).

This sits at the intersection of security and performance testing and is often missed entirely.