@ArgumentsSource with custom providers in JUnit - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the @ArgumentsSource annotation in JUnit?

It allows you to provide custom argument sources for parameterized tests by specifying a class that implements the <code>ArgumentsProvider</code> interface.

beginner

What interface must a custom argument provider implement to be used with @ArgumentsSource?

The custom provider must implement the ArgumentsProvider interface and override the provideArguments(ExtensionContext context) method.

intermediate

How does the provideArguments method work in a custom ArgumentsProvider?

It returns a Stream<Arguments> that supplies the test method with different sets of parameters for each test invocation.

intermediate

Why would you use a custom @ArgumentsSource instead of built-in sources like @ValueSource or @CsvSource?

Custom providers let you generate complex or dynamic test data that built-in sources cannot easily provide, such as data from files, databases, or computed values.

beginner

Show a simple example of a custom <code>ArgumentsProvider</code> class for <code>@ArgumentsSource</code>.

public class SimpleArgumentsProvider implements ArgumentsProvider {
  @Override
  public Stream<Arguments> provideArguments(ExtensionContext context) {
    return Stream.of(
      Arguments.of("apple", 1),
      Arguments.of("banana", 2)
    );
  }
}

Which interface must a class implement to be used with @ArgumentsSource in JUnit?

A TestTemplateInvocationContextProvider

B TestSource

C ArgumentsProvider

D ParameterResolver

The ArgumentsProvider interface is required to supply arguments for parameterized tests using @ArgumentsSource.

What does the provideArguments method return in a custom ArgumentsProvider?

A Stream<Arguments>

B List<String>

C Set<Object>

D Map<String, Object>

The method returns a Stream<Arguments> to supply multiple argument sets to the test method.

Why use a custom @ArgumentsSource instead of @ValueSource?

A To generate complex or dynamic test data

B Because <code>@ValueSource</code> is deprecated

C To provide simple fixed values only

D To run tests without parameters

Custom providers allow complex or dynamic data, such as from files or computations, which @ValueSource cannot handle.

Which of these is a valid way to use @ArgumentsSource in a test method?

A @ArgumentsSource("SimpleArgumentsProvider") void test(String fruit) { ... }

B @ArgumentsSource(SimpleArgumentsProvider.class) void test(String fruit, int number) { ... }

C @ArgumentsSource void test(int number) { ... }

D @ArgumentsSource(SimpleArgumentsProvider) void test() { ... }

You must specify the class with .class and match the method parameters to the arguments provided.

What happens if your custom ArgumentsProvider returns an empty stream?

A The test runs once with null arguments

B JUnit throws an exception

C The test is skipped

D The test runs zero times (no invocations)

If no arguments are provided, the parameterized test runs zero times.

Explain how to create and use a custom argument provider with @ArgumentsSource in JUnit.

Think about the steps to supply custom data to parameterized tests.

Describe scenarios where using a custom @ArgumentsSource is better than built-in sources.

Consider when simple fixed values are not enough.

Practice

1. What is the main purpose of using @ArgumentsSource in JUnit tests?

easy

A. To mark a test method as disabled

B. To provide custom test data from a class implementing ArgumentsProvider

C. To specify the order of test execution

D. To inject mock objects into tests

Solution

1. Step 1: Understand the role of @ArgumentsSource

   This annotation is used to supply custom arguments to parameterized tests by referencing a class that implements ArgumentsProvider.

2. Step 2: Differentiate from other annotations

   Other options like disabling tests or ordering are handled by different annotations, not @ArgumentsSource.

3. Final Answer:

   To provide custom test data from a class implementing ArgumentsProvider -> Option B

4. Quick Check:

   @ArgumentsSource supplies custom test data [OK]

Hint: Remember: @ArgumentsSource links to custom data providers [OK]

Common Mistakes:

• Confusing @ArgumentsSource with @Disabled
• Thinking it controls test order
• Assuming it injects mocks

2. Which of the following is the correct way to declare a custom ArgumentsProvider class for use with @ArgumentsSource?

easy

A. public class MyProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(1)); } }

B. public class MyProvider { public Stream<Arguments> provideArguments() { return Stream.of(Arguments.of(1)); } }

C. public class MyProvider implements ArgumentsSource { public Stream<Arguments> provideArguments() { return Stream.of(Arguments.of(1)); } }

D. public class MyProvider implements ArgumentsProvider { public List<Arguments> provideArguments() { return List.of(Arguments.of(1)); } }

Solution

1. Step 1: Check interface implementation and method signature

   The class must implement ArgumentsProvider and override provideArguments(ExtensionContext) returning a Stream<Arguments>.

2. Step 2: Validate return type and method parameters

   public class MyProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(1)); } } correctly implements the interface and method signature. public class MyProvider { public Stream<Arguments> provideArguments() { return Stream.of(Arguments.of(1)); } } misses the interface and method parameter. public class MyProvider implements ArgumentsSource { public Stream<Arguments> provideArguments() { return Stream.of(Arguments.of(1)); } } wrongly implements ArgumentsSource which is an annotation, not an interface. public class MyProvider implements ArgumentsProvider { public List<Arguments> provideArguments() { return List.of(Arguments.of(1)); } } returns a List instead of a Stream.

3. Final Answer:

   public class MyProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(1)); } } -> Option A

4. Quick Check:

   Implement ArgumentsProvider with correct method signature [OK]

Hint: Implement ArgumentsProvider with provideArguments(ExtensionContext) [OK]

Common Mistakes:

• Forgetting to implement ArgumentsProvider
• Wrong method signature or missing parameter
• Returning List instead of Stream
• Confusing ArgumentsSource annotation with interface

3. Given the following custom provider and test method, what will be the output when the test runs?

public class NumberProvider implements ArgumentsProvider {
    public Stream<Arguments> provideArguments(ExtensionContext context) {
        return Stream.of(Arguments.of(2), Arguments.of(4));
    }
}

@ParameterizedTest
@ArgumentsSource(NumberProvider.class)
void testIsEven(int number) {
    assertTrue(number % 2 == 0);
}

medium

A. Compilation error due to missing annotation

B. Test fails because 4 is not even

C. Both tests pass because 2 and 4 are even numbers

D. Test fails because 2 is not even

Solution

1. Step 1: Analyze the provided arguments

   The provider returns two arguments: 2 and 4, both even numbers.

2. Step 2: Check the assertion logic

   The test asserts that the number modulo 2 equals 0, which is true for both 2 and 4.

3. Final Answer:

   Both tests pass because 2 and 4 are even numbers -> Option C

4. Quick Check:

   2 % 2 == 0 and 4 % 2 == 0 [OK]

Hint: Check if all provided numbers satisfy the assertion condition [OK]

Common Mistakes:

• Assuming 4 is odd
• Ignoring the assertion logic
• Confusing test failure with compilation error

4. Identify the error in the following custom ArgumentsProvider implementation:

public class StringProvider implements ArgumentsProvider {
    public List<Arguments> provideArguments(ExtensionContext context) {
        return List.of(Arguments.of("test"));
    }
}

medium

A. Method name should be getArguments instead of provideArguments

B. Class must implement ArgumentsSource instead of ArgumentsProvider

C. No error, code is correct

D. Method should return Stream<Arguments>, not List<Arguments>

Solution

1. Step 1: Check the return type of provideArguments

   The ArgumentsProvider interface requires provideArguments to return a Stream<Arguments>, but the code returns a List<Arguments>.

2. Step 2: Validate interface and method name

   The class correctly implements ArgumentsProvider and the method name is correct.

3. Final Answer:

   Method should return Stream<Arguments>, not List<Arguments> -> Option D

4. Quick Check:

   Return type must be Stream<Arguments> [OK]

Hint: Remember: provideArguments returns Stream, not List [OK]

Common Mistakes:

• Returning List instead of Stream
• Confusing interface with annotation
• Wrong method name

5. You want to test a method that accepts a pair of integers and returns their sum. You decide to use @ArgumentsSource with a custom provider that supplies pairs. Which of the following ArgumentsProvider implementations correctly provides pairs of integers for the test?

hard

A. public class PairProvider implements ArgumentsProvider {
public Stream<Arguments> provideArguments(ExtensionContext context) {
return Stream.of(Arguments.of(1, 2), Arguments.of(3, 4));
}
}

B. public class PairProvider implements ArgumentsProvider {
public Stream<Arguments> provideArguments(ExtensionContext context) {
return Stream.of(Arguments.of(new int[]{1, 2}), Arguments.of(new int[]{3, 4}));
}
}

C. public class PairProvider implements ArgumentsProvider {
public Stream<Arguments> provideArguments(ExtensionContext context) {
return Stream.of(Arguments.of(List.of(1, 2)), Arguments.of(List.of(3, 4)));
}
}

D. public class PairProvider implements ArgumentsProvider {
public Stream<Arguments> provideArguments(ExtensionContext context) {
return Stream.of(Arguments.of(1), Arguments.of(2), Arguments.of(3), Arguments.of(4));
}
}

Solution

1. Step 1: Understand the test method parameters

   The test method expects two integer parameters per test invocation, so each Arguments must supply two integers.

2. Step 2: Evaluate each provider's argument format

   public class PairProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(1, 2), Arguments.of(3, 4)); } } correctly provides pairs of integers as separate arguments. public class PairProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(new int[]{1, 2}), Arguments.of(new int[]{3, 4})); } } provides arrays which may not match the method signature expecting two int parameters. public class PairProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(List.of(1, 2)), Arguments.of(List.of(3, 4))); } } provides lists which also do not match two int parameters directly. public class PairProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(1), Arguments.of(2), Arguments.of(3), Arguments.of(4)); } } provides single integers, not pairs.

3. Final Answer:

   public class PairProvider implements ArgumentsProvider { public Stream<Arguments> provideArguments(ExtensionContext context) { return Stream.of(Arguments.of(1, 2), Arguments.of(3, 4)); } } -> Option A

4. Quick Check:

   Each Arguments.of() must match method parameters [OK]

Hint: Match Arguments.of() parameters count to test method parameters [OK]

Common Mistakes:

• Passing arrays or lists instead of separate parameters
• Providing single arguments when pairs are needed
• Not matching argument count to method parameters