@TestFactory is used to signal that the annotated method is a
test factory method.
In contrast to @Test methods, a test factory is not itself
a test case but rather a factory for test cases.
@TestFactory methods must not be private or static
and must return a Stream, Collection, Iterable,
Iterator, or array of DynamicNode instances. Supported
subclasses of DynamicNode include DynamicContainer and
DynamicTest. Dynamic tests will be executed lazily,
enabling dynamic and even non-deterministic generation of test cases.
Any Stream returned by a @TestFactory will be properly
closed by calling stream.close(), making it safe to use a resource
such as Files.lines() as the initial source of the stream.
@TestFactory methods may optionally declare parameters to be
resolved by ParameterResolvers.
Test Execution Order
By default, test methods will be ordered using an algorithm that is
deterministic but intentionally nonobvious. This ensures that subsequent runs
of a test suite execute test methods in the same order, thereby allowing for
repeatable builds. In this context, a test method is any instance
method that is directly annotated or meta-annotated with @Test,
@RepeatedTest, @ParameterizedTest, @TestFactory, or
@TestTemplate.
Although true unit tests typically should not rely on the order
in which they are executed, there are times when it is necessary to enforce
a specific test method execution order — for example, when writing
integration tests or functional tests where the sequence of
the tests is important, especially in conjunction with
@TestInstance(Lifecycle.PER_CLASS).
To control the order in which test methods are executed, annotate your
test class or test interface with @TestMethodOrder
and specify the desired MethodOrderer implementation.
- Since:
- 5.0
- See Also: