In a Karate feature file, `* def foo = [1, 2, 3, 5]`. Does `match foo !contains [5, 6]` pass, and what exactly does `!contains` negate?

## `!contains` is one negation, not many `!contains` is written as a single token — the `!` is glued to `contains` with no space — and it is implemented as a wrapper: run the plain `contains` comparison, then invert the result. Everything surprising about it follows from that one sentence, because `contains` itself is an **all** check. For the example: 1. `contains [5, 6]` searches the actual array for `5` — found at the last index. 2. It searches for `6` — not found, so `contains` fails. 3. `!contains` inverts that failure into a pass. So `match foo !contains [5, 6]` passes on `[1, 2, 3, 5]`. The step did not assert that neither `5` nor `6` is present; it asserted that they are not **both** present. Read aloud, the correct gloss is *"it is not the case that all of these are present"*. ## The safe form The ambiguity exists only for a multi-item expected value, so: - **Write one item per step.** `match foo !contains 4` is unambiguous — a single-element expected value makes "not all present" and "none present" the same statement. - For several forbidden values, write several steps rather than one list. - `match foo !contains [5, 6]` is not wrong; it just means less than it looks like it means. ```gherkin * def foo = [1, 2, 3, 5] # unambiguous, one forbidden value per step * match foo !contains 4 * match foo !contains 6 # passes, because 6 is missing - NOT because 5 is missing * match foo !contains [5, 6] ``` ## The object case: absent and different look the same The same inversion produces a second blind spot for maps: ```gherkin * def foo = { bar: 1, baz: 'hello' } * match foo !contains { bar: 2 } * match foo !contains { huh: '#notnull' } ``` Both steps pass, but for different underlying reasons: the first because `bar` exists with a different value, the second because `huh` does not exist at all. `contains` fails in both cases and the negation cannot tell you which. If you specifically need *"this key must not exist"*, do not use `!contains` — use an equality match with a `#notpresent` marker at that path, which states absence directly and fails if the key appears holding anything. One further edge worth knowing, and it is the one place the two Karate lines disagree. On Karate 1.x **`match someMap !contains {}` always passes**: the negation operator hard-codes an early return for an empty expected map — the source comment calls it a hack — whatever the actual holds. `contains {}` always passes on both lines. 2.x dropped the special case, so `!contains {}` still passes against a non-empty map but **fails** when the actual map is empty as well: the comparison then succeeds and the negation inverts it. Either way, an expected object that collapses to `{}` at runtime has stopped asserting what its author meant. ## Arrays and objects fail the same test differently It is worth being precise about which comparison is being inverted, because the two actual types reach failure by different routes: | actual | `contains` fails when | so `!contains` passes when | |---|---|---| | array | any one expected item is missing | not every expected item is present | | object | any expected key is missing, or its value does not match | not every expected pair matches | In both rows the negation is a claim about the **conjunction**, never about the individual items, and neither row tells you which item was responsible. That is the whole of it. ## What does not exist - **There is no `!contains deep`.** The negated deep operator was never implemented — the operator set has no entry for it. To assert that something nested is absent, target the nested path directly or use `#notpresent` in an equality match. - **There is no `!contains only` and no `!contains any` either.** Plain `contains` is the only member of the family with a negated spelling. On Karate 1.x the step parser reads the `only` and `any` modifiers before it ever looks at the `!`, so `match foo !contains only [...]` parses and runs as `contains only` with the negation silently dropped — the opposite assertion, green with no warning. On 2.x the token is not a recognised operator and the step is rejected outright. - **`each !contains` does exist**, and applies the negation to every element of an array: `match each response !contains { error: '#notnull' }`. - The inline form is `'#(!^part)'`, which is the embedded-expression spelling of `!contains` and composes the same way as the positive prefixes. ## Reviewing a `!contains` step Three questions catch nearly every misuse: 1. **How many items are on the right?** More than one, and the step means "not all", which is almost never what the author meant. 2. **Is the intent "absent" or "different"?** If it is absent, `#notpresent` says so and `!contains` does not. 3. **Can the expected value be empty at runtime?** If it is built from a variable or read from a file, `{}` is reachable, and the step stops asserting what you meant — silently green on 1.x, and on 2.x green or red depending on whether the actual happens to be empty too. A negative assertion is the one kind that fails silently in the wrong direction: when it is too weak it simply keeps passing, and nothing in the report says so.