A JUnit 5 suite keeps growing its test tables inside @CsvSource annotations. When would you move that data out into CSV files read by @CsvFileSource, and what problems — encoding, oversized values, quoting, missing files — should you expect after the move?

## The decision, framed properly Inline versus external is not a style preference; it is a question of **who owns the data and how often it changes**. Inline `@CsvSource` wins when the cases are an argument *about the code*: three boundary values that explain what the method does. Reviewers read the assertion and the data in one glance, and the fixture cannot drift away from the test. `@CsvFileSource` wins when the data is a *thing*: a hundred tax brackets, an exported golden set from a legacy system, a table QA maintains, a set of cases shared by three different tests. Once the data has its own change cadence and its own authors, keeping it inside an annotation forces those people to edit Java and forces every data change through a code diff that hides the actual delta. Useful thresholds in practice: more than roughly 15–20 rows, more than one test consuming the same rows, or any non-developer expected to edit it. Below all three, stay inline. ## What the move costs ### Quoting semantics change This catches almost everyone. `@CsvSource`'s default quote character is the **single quote**; `@CsvFileSource`'s is the **double quote**. Copying rows verbatim from an annotation into a file leaves `'lemon, lime'` as three columns (with stray apostrophes) instead of one. Either rewrite the quoting to `"lemon, lime"` or set `quoteCharacter = '\''` explicitly. Decide once per project and be consistent, because the failure mode — a wrong argument count on one row of a hundred — is annoying to hunt. ### Headers are data until you say otherwise `numLinesToSkip` defaults to `0`. A file with `income,region,expected` at the top produces a first invocation that tries to convert `"income"` to `int` and fails. Setting `numLinesToSkip = 1` is the fix, and a header line is worth keeping — it is the only documentation the file has. ### Encoding and line endings `encoding` defaults to `"UTF-8"` and `lineSeparator` to `"\n"`. Files exported from Excel on Windows commonly arrive as CP1252 or UTF-16 with CRLF endings. CRLF usually survives because the carriage return is trimmed as whitespace, but a charset mismatch does *not* throw — it silently substitutes characters, so a test comparing `Müller` fails with a diff you have to squint at. When a fixture contains non-ASCII data, pin `encoding` explicitly and add one row of non-ASCII data as a canary. ### Oversized cells The CSV parser guards against pathological input with `maxCharsPerColumn`, whose default is around 4096 characters. A cell holding a large JSON payload or a long SQL statement trips it with an explicit "value is too long" style error. You can raise the limit, but the better reading is usually that CSV is the wrong container: a payload that big wants to be its own file, loaded by a `@MethodSource` factory that reads the directory and yields one `Arguments` per file. ### The file must actually be found Use `resources` (classpath) rather than `files` (filesystem) for anything that ships with the project. Put the file in `src/test/resources` so the build copies it to the test classpath, and prefer an absolute resource path (`"/cases/tax.csv"`), because a path without a leading slash resolves relative to the test class's package. A missing resource fails loudly, which is good — but a *stale* one does not, so a fixture that moved package while the test kept a relative path can quietly load the wrong file if a same-named one exists. Absolute paths remove the ambiguity. ### Rename and refactor safety The last cost is tooling: a file path in a string is invisible to rename refactorings and to "find usages". Nothing in the compiler links `tax.csv` to the test that reads it. Mitigate by co-locating files in a directory named after the feature and by keeping the number of external fixtures small enough to enumerate. ## What externalising does *not* buy you It does not make the data type-safe, it does not let you express objects or collections, and it does not help when rows must be generated. If you find yourself writing parsing helpers to turn CSV columns into domain objects inside the test, the correct move was never `@CsvFileSource` — it was `@MethodSource` with a factory that builds the objects directly. ## A workable house rule Inline tables up to about a screenful, with the text-block form and aligned columns. Beyond that, one `.csv` per feature under `src/test/resources`, referenced by absolute path, always with a header line and `numLinesToSkip = 1`, an explicit `encoding` when non-ASCII data is present, and `nullValues` covering whatever "nothing" looks like to whoever edits the file. Anything that will not fit that shape belongs to a factory method, not to CSV.