In a Karate feature file, `* def original = { a: 1, b: 2, c: 3, d: { a: 1, b: 2 } }`. Why does `match original contains { a: 1, d: { b: 2 } }` fail, and which operator makes it pass?

## One level of leniency, not all of them The rule worth memorising is short: **`contains` is lenient at the level it is applied to, and only at that level.** Internally the comparison chooses a child operator for every value it descends into, and for plain `contains` that child operator is always equality. `contains deep` is the variant that keeps handing containment down. Walk the example step by step: 1. The operator is `contains`, so the expected map `{ a: 1, d: { b: 2 } }` drives the walk. 2. Key `a` is found on the actual side; its value is a scalar, so it is compared with `==`. `1 == 1` passes. 3. Key `d` is found; its actual value is a **nested object**. Because the operator is not deep, the child comparison is equality. 4. `{ a: 1, b: 2 } == { b: 2 }` fails — under `==` the expected literal must describe the whole object, and the actual object carries one more key. Nothing about step 4 is special-cased for nesting; it is simply what `==` means, applied one level down. ## `contains deep` `contains deep` changes exactly step 3. Whenever the value being descended into is a map, a list or XML, the child comparison stays in the containment family instead of collapsing to equality. Scalars are still compared with `==`, because there is no such thing as a partial number. ```gherkin Scenario: recurse nested json * def original = { a: 1, b: 2, c: 3, d: { a: 1, b: 2 } } * def expected = { a: 1, c: 3, d: { b: 2 } } * match original contains deep expected Scenario: recurse nested array * def original = { a: 1, arr: [ { b: 2, c: 3 }, { b: 3, c: 4 } ] } * def expected = { a: 1, arr: [ { b: 2 }, { c: 4 } ] } * match original contains deep expected ``` The second scenario shows why this matters for real payloads: the elements of `arr` are matched as partial objects, and because array containment is order-free, `{ c: 4 }` finds the second element even though it was written second and the first element does not contain it. ## The family at a glance | operator | top level | nested maps and lists | |---|---|---| | `==` | must describe the whole value | must describe the whole value | | `contains` | subset | full equality | | `contains deep` | subset | subset, all the way down | | `contains only deep` | same elements, any order | same elements, any order, at every depth | `contains only deep` is the mirror image and worth knowing for one specific job: it behaves like `==` except that array order is ignored **at every depth**, so `{ foo: ['a', 'b'] }` matches `contains only deep { foo: ['b', 'a'] }` while still failing if a key is missing or extra. ## Two denials that catch people out - **There is no `!contains deep`.** The negated deep type simply does not exist in the operator set, and the documentation says as much. If you need to assert that a nested chunk is absent, reach for a marker such as `#notpresent` in an equality match, or assert on the specific path. - **`each` does not combine with every deep spelling.** `match each x contains deep y` is a real operator, but the only-deep and any-deep spellings have no `each` counterpart, so do not assume the grid is complete just because the two words each exist. ## Why this bites in practice Response payloads nest. A typical assertion starts life as `match response contains { status: 'OK' }`, passes for months, and then someone adds `data: { id: '#number' }` to the expected object because the payload grew. That new line silently changes the contract for `data` from "contains" to "must be exactly this", and the step starts failing the day the service adds a field inside `data` — which is the opposite of what the author of the `contains` step wanted. The same trap applies to XML, which is converted to a map before comparison, so a partial subtree under a nested element needs the deep form too. The tell in a failure report is that the reported path points at a **nested** key while the message reads like an equality failure. When you see that under a `contains` step, the fix is almost always `contains deep` rather than more expected keys.