A JUnit 5 parameterized test method mixes plain indexed arguments, an ArgumentsAccessor or @AggregateWith parameter, and a TestInfo injected by the framework. What ordering rules apply to those parameters, and what happens if you get the order wrong?

## Three kinds of parameters, one fixed order A `@ParameterizedTest` method's formal parameters are not all fed from the same place. Jupiter classifies each one: - **Indexed** — an ordinary parameter that takes the next value from the argument row supplied by `@CsvSource`, `@MethodSource`, `@ValueSource`, and friends. Position *n* in this group takes value *n* of the row. - **Aggregator** — a parameter whose type is `ArgumentsAccessor`, or which is annotated (directly or via a composed annotation) with `@AggregateWith`. It consumes no value from the row; instead it is given a view over the whole row. - **Resolver-supplied** — a parameter that some registered `ParameterResolver` extension handles: `TestInfo`, `TestReporter`, `RepetitionInfo`, temp-dir paths, Spring beans, Mockito `@Mock` parameters, and anything a custom extension resolves. JUnit requires them in exactly that sequence: indexed, then aggregators, then resolver-supplied. `void test(String id, int qty, ArgumentsAccessor all, TestInfo info)` is valid. `void test(ArgumentsAccessor all, String id)` and `void test(String id, TestInfo info, int qty)` are not. ## Why the rule exists Binding is positional and the three groups are counted differently. Indexed parameters consume row values in order; aggregators consume none but must be told where the indexed run stops; resolver parameters consume none either but are matched by extensions. Without a fixed order, a signature like `(String, ArgumentsAccessor, String)` would be ambiguous — does the trailing `String` take row value 1 or row value 2? The ordering rule removes the ambiguity: everything before the first aggregator is indexed, and nothing after an aggregator may be indexed. Note that the aggregator's own indices are unaffected by how many indexed parameters precede it. In `void t(String id, ArgumentsAccessor args)` with row `"A, 1, 2"`, `args.get(0)` is still `"A"`. The accessor is a view over the complete row, not over the leftovers. ## What failure looks like A violation is detected while JUnit builds the parameterized-method context — before any invocation. The test does not fail once per row; the whole method fails with a single error whose message states that argument aggregators must be declared after any indexed arguments and before any arguments resolved by another `ParameterResolver`. In an IDE this shows up as the method being red with zero invocations, which is the important diagnostic clue: a per-row failure points at your data or code, a zero-invocation failure points at the signature or the source configuration. A related and more confusing symptom appears when a resolver-supplied parameter is placed in the middle of indexed ones: Jupiter counts it as indexed and you get an arity or conversion complaint about the row being too short or a value not converting to `TestInfo`, which sends people hunting in the CSV instead of the signature. ## Multiple aggregators More than one aggregator parameter is allowed, and they must all sit in the middle group. Each receives the same complete row. Splitting a row into an input object and an expected-result object with two aggregators is the standard use of this, and it is why the rule is phrased as "aggregators" plural rather than "the aggregator". ## Practical guidance - Read a failing signature left to right and mentally label each parameter I (indexed), A (aggregator), R (resolver). The labels must be non-decreasing in that order. - If you need `TestInfo` or a `TempDir`, push it to the end — always. - If a method needs many resolver-supplied collaborators plus a wide row, that is usually a signal to move the collaborators into fields injected at the class level and keep the method signature about the data. - Because the rule is validated per method, it is cheap to verify: run the single method; if it reports zero invocations with a configuration error, the signature is the suspect, not the data source. ## Interaction with the parameter count The number of indexed parameters need not equal the row's arity: a row may supply more values than there are indexed parameters, and the extras are simply not bound (they remain visible to an aggregator). Supplying *fewer* values than indexed parameters is an error. Combining that with the ordering rule explains a frequent pattern: declare the two or three columns you assert on as indexed parameters for readability, add an `ArgumentsAccessor` at the end for the long tail of extra columns, and keep any `TestInfo` last of all.