How do you point a JUnit 5 @MethodSource at a factory method that lives in a different class, and why would you keep shared test data there rather than duplicating it in each test class?

## The syntax A `@MethodSource` value is normally a bare method name resolved inside the test class. It can instead be a **fully qualified reference**: ``` <fully.qualified.ClassName>#<methodName> ``` ```java @ParameterizedTest @MethodSource("com.acme.fixtures.EmailFixtures#validAddresses") void acceptsValidAddresses(String address) { assertTrue(EmailValidator.isValid(address)); } ``` Rules that apply: - **The external method must be `static`.** `@TestInstance(PER_CLASS)` relaxes the static requirement only for factories declared in the test class itself; there is no instance of a foreign fixture class for JUnit to use. - **It must be reachable** from the test class — same module/classpath, and not `private` to another class (a `private` factory works only inside the declaring test class, where reflection has the necessary access; for a foreign class use at least package-private in the same package, or `public`). - **Overloads can be disambiguated** by adding a parameter-type list: `"com.acme.Fixtures#values(java.lang.String)"`. In practice, avoid overloading fixture factories at all and the question never arises. - **Several references can be listed:** `@MethodSource({"com.acme.Fixtures#happy", "com.acme.Fixtures#edge"})` concatenates the element sequences. The return-type and element-shape rules are unchanged: a `Stream`/`Iterable`/array of `Arguments` for multi-parameter tests, of bare values for single-parameter ones. ## Why centralise the data ### One authoritative case set Some sets of inputs are facts about the domain, not about one test: the valid and invalid email formats, the currency codes you support, the IBAN samples, the malformed-payload corpus, every enum-plus-expected-label pairing. Several tests care about them — a validator unit test, a mapper test, a serialization round-trip test, a controller slice test. If each class keeps its own copy, they drift. Someone finds a new edge case (an address with a plus tag, an IBAN with lowercase letters), fixes the validator, and adds the case to *one* test. The other three keep passing against their stale copies, and the next regression slips through the ones that were never updated. A shared factory makes the improvement automatic: add the case once, and every consuming test immediately covers it. ### It is code, not a string Comparing with the file-based alternative (`@CsvFileSource`): a shared fixture class is compiled Java. Rename refactorings, "find usages", type checking and IDE navigation all work on the *method*. The one weak link is the class-name string inside the annotation — many IDEs resolve and refactor it, but it is not a compiler guarantee, so a moved fixture class can leave a dangling reference that only fails at run time with a "could not load class" style error. Keeping fixtures in a stable, rarely moved package limits that exposure. ### Naming as documentation `EmailFixtures.validAddresses()` says what the data is. The same rows inlined in a `@CsvSource` say nothing beyond their contents. Good fixture names turn the test signature into a readable sentence: *this test accepts all valid addresses*. ## The costs, stated honestly **Indirection.** A reader of the test can no longer see the data. For three obvious cases this is a net loss — keep them inline. Externalise when the set is either large or genuinely shared. **Coupling.** Once five tests consume one factory, adding a case can break tests you were not thinking about. That is usually a feature (it found a real gap), but it does mean the factory is now shared code and deserves the same care as production code: stable name, focused scope, a comment explaining what the set is meant to represent. **Temptation to over-generalise.** A `TestData` class that accumulates every fixture in the project becomes a junk drawer. Prefer several small, domain-named fixture classes (`EmailFixtures`, `IbanFixtures`) over one god class, and keep each factory's set narrow enough that its name is honest. ## Where to put fixtures A common layout is a `fixtures` (or `testdata`) package under `src/test/java`, mirroring the production package it supports. If two Gradle/Maven modules need the same fixtures, the data has to move into a shared test-fixtures artefact — at that point you are publishing test data as a real dependency, and it deserves an explicit decision rather than a copy-paste. ## Composing with other sources A shared factory pairs naturally with the multi-value form: a test can take the shared happy-path set plus a locally declared edge case, listing both names. And when the same *annotation* configuration recurs, wrap it in a custom composed annotation (`@ValidEmails`) that carries the `@MethodSource` reference — consumers then never repeat the fully qualified string, which also removes the fragile-string problem from every call site but one. ## Interview summary Syntax `FQCN#method`, method must be static and reachable, overloads disambiguated with a parameter-type list, several references may be listed. Do it when the case set is shared or large; keep it inline when it is small and local; treat the fixture class as shared code with a real name and a narrow scope.