@ArgumentsSource with custom providers in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a JUnit test using @ArgumentsSource with a custom provider

Given the following JUnit 5 test code using a custom ArgumentsProvider, what will be the output when the test runs?

JUnit

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.ArgumentsSource;
import org.junit.jupiter.api.extension.ExtensionContext;
import org.junit.jupiter.params.provider.ArgumentsProvider;
import java.util.stream.Stream;
import static org.junit.jupiter.api.Assertions.assertTrue;

class CustomProviderTest {
    static class EvenNumberProvider implements ArgumentsProvider {
        @Override
        public Stream<? extends Arguments> provideArguments(ExtensionContext context) {
            return Stream.of(2, 4, 6, 7).map(Arguments::of);
        }
    }

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

A Test does not run due to compilation error

B Test passes for all inputs

C Test fails with NullPointerException

D Test fails with AssertionError on input 7

💡 Hint

Check which numbers are provided and what the assertion checks.

The custom provider supplies numbers 2, 4, 6, and 7. The test asserts that each number is even. Since 7 is not even, the assertion fails causing the test to fail with an AssertionError.

❓ assertion

intermediate

Correct assertion for a parameterized test using @ArgumentsSource

You have a parameterized test using a custom ArgumentsProvider that supplies strings. Which assertion correctly verifies that each string is not empty?

JUnit

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ArgumentsSource;
import static org.junit.jupiter.api.Assertions.*;

class StringTest {
    @ParameterizedTest
    @ArgumentsSource(NonEmptyStringProvider.class)
    void testNonEmptyStrings(String input) {
        // Which assertion is correct here?
    }
}

A assertFalse(input.isEmpty());

B assertEquals("", input);

C assertNotNull(input);

D assertTrue(input.length() > 0);

💡 Hint

Check which assertion directly tests that the string is not empty.

assertFalse(input.isEmpty()) directly checks that the string is not empty. assertTrue(input.length() > 0) also works but is less readable. assertNotNull only checks for null, not emptiness. assertEquals("", input) checks for empty string, which is opposite of the requirement.

🔧 Debug

advanced

Identify the cause of test failure with a custom ArgumentsProvider

A parameterized test using a custom ArgumentsProvider fails with the error: "java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer". What is the most likely cause?

JUnit

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ArgumentsSource;

class NumberTest {
    @ParameterizedTest
    @ArgumentsSource(StringToIntegerProvider.class)
    void testNumber(Integer number) {
        // test logic
    }
}

A The ArgumentsProvider returns Strings but the test expects Integers

B The test method parameter type is incorrect and should be String

C The ArgumentsProvider is missing the @Override annotation

D The test method is missing the @Test annotation

💡 Hint

Check the types returned by the provider and the test method parameter type.

The ClassCastException indicates the provider returns String objects but the test method expects Integer parameters. This mismatch causes the failure.

❓ framework

advanced

Behavior of @ArgumentsSource with multiple providers

What happens if a parameterized test method is annotated with multiple @ArgumentsSource annotations providing different argument streams?

JUnit

@ParameterizedTest
@ArgumentsSource(ProviderOne.class)
@ArgumentsSource(ProviderTwo.class)
void testMultipleSources(String input) {
    // test logic
}

A JUnit runs the test only with arguments from the first provider

B JUnit combines all arguments from both providers and runs the test for each argument

C JUnit throws a runtime exception due to multiple @ArgumentsSource annotations

D JUnit runs the test only with arguments from the last provider

💡 Hint

Check JUnit 5 documentation on multiple @ArgumentsSource annotations on the same method.

JUnit 5 does not support multiple @ArgumentsSource annotations on the same test method. This causes a runtime exception.

🧠 Conceptual

expert

Custom ArgumentsProvider lifecycle and state management

Consider a custom ArgumentsProvider that maintains internal state between calls to provideArguments. What is the recommended practice regarding state in such providers?

A ArgumentsProvider should maintain mutable state to track test progress

B ArgumentsProvider instances should be stateless because JUnit may create multiple instances

C ArgumentsProvider must be a singleton to preserve state across tests

D ArgumentsProvider should store state in static fields to share across tests

💡 Hint

Think about how JUnit creates and uses ArgumentsProvider instances during test execution.

JUnit may create multiple instances of ArgumentsProvider, so relying on internal mutable state is unsafe. Providers should be stateless or use external mechanisms for state.

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