Package-level test organization in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why organize tests at the package level?

In JUnit testing, what is the main advantage of organizing tests at the package level?

A It automatically generates test data for all classes in the package.

B It allows running all tests in a package together, improving test management and reporting.

C It prevents tests from accessing classes outside their package, increasing security.

D It forces tests to be run only one by one, reducing parallel execution.

💡 Hint

Think about how grouping tests helps when running many tests.

Organizing tests by package lets you run all tests in that package at once, making it easier to manage and see results collectively.

❓ Predict Output

intermediate

JUnit package-level test suite execution result

Given this JUnit 5 package-level test suite setup, what will be the output when running the suite?

JUnit

package com.example.tests;

import org.junit.platform.suite.api.SelectPackages;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectPackages("com.example.tests.unit")
public class UnitTestsSuite {
}

// Assume com.example.tests.unit contains 3 test classes each with 2 tests, all passing.

A The suite runs only one test from each class, total 3 tests.

B The suite runs no tests because @SelectPackages is ignored at class level.

C The suite runs all 6 tests from the 3 classes and reports all passed.

D The suite runs tests but reports failures due to missing @Test annotations.

💡 Hint

Check how @SelectPackages works with @Suite in JUnit 5.

@SelectPackages tells JUnit to run all tests in the specified package. Since each class has 2 passing tests, total 6 tests run and pass.

❓ locator

advanced

Best locator for package-level test suite class

Which of the following is the best Java package and class name for a package-level test suite that runs all tests in com.app.services?

A com.app.services.ServiceTestSuite

B com.app.AllServicesSuite

C com.app.services.testsuite

D com.app.services.AllServicesTests

💡 Hint

Consider Java naming conventions and clarity for test suite classes.

Option A uses proper camel case and clearly indicates it is a test suite for services in the package.

❓ assertion

advanced

Assertion to verify package-level test suite runs all tests

In a JUnit 5 test suite that runs all tests in com.example.api, which assertion best verifies that exactly 10 tests were executed?

A assertEquals(10, testExecutionSummary.getTestsFailedCount())

B assertTrue(testExecutionSummary.getTestsFoundCount() == 10)

C assertEquals(10, testExecutionSummary.getTestsSucceededCount())

D assertEquals(10, testExecutionSummary.getTestsStartedCount())

💡 Hint

Think about which count reflects total tests run, regardless of pass/fail.

getTestsStartedCount() returns the number of tests that started execution, matching total tests run.

❓ framework

expert

Debugging package-level test suite execution failure

You created a JUnit 5 package-level test suite using @Suite and @SelectPackages("com.app.features"), but no tests run. What is the most likely cause?

A The package name in @SelectPackages is misspelled or does not match actual package.

B The suite class is missing the @RunWith annotation.

C The test classes in com.app.features lack @Test annotations on methods.

D JUnit 5 does not support package-level test suites.

💡 Hint

Check the package name spelling and case carefully.

If the package name in @SelectPackages does not exactly match the package containing tests, no tests will be found or run.

Practice

1. Why is it recommended to organize JUnit test classes in the same package as the source code they test?

easy

A. JUnit requires tests to be in the same package to run.

B. It makes tests easier to find and run selectively.

C. It prevents tests from accessing package-private code.

D. It automatically runs tests without any configuration.

Solution

1. Step 1: Understand package organization purpose

   Organizing tests in the same package as source code helps developers find related tests quickly.

2. Step 2: Benefits of package-level organization

   This organization allows running tests selectively by package and keeps the project clean and maintainable.

3. Final Answer:

   It makes tests easier to find and run selectively. -> Option B

4. Quick Check:

   Package-level test organization = easier test management [OK]

Hint: Tests in same package as code = easier to find and run [OK]

Common Mistakes:

• Thinking JUnit forces tests in same package
• Believing tests cannot access package-private code
• Assuming tests run automatically without setup

2. Which of the following is the correct way to place a JUnit test class for a source class com.example.service.UserService?

easy

A. In package com.example under the test source folder

B. In package com.example.test under the main source folder

C. In package com.example.service under the main source folder

D. In package com.example.service under the test source folder

Solution

1. Step 1: Identify source package and test source folder

   The source class is in com.example.service. Tests should be in the same package but under the test source folder.

2. Step 2: Match test class package and location

   In package com.example.service under the test source folder places the test class in com.example.service under the test source folder, which is correct.

3. Final Answer:

   In package com.example.service under the test source folder -> Option D

4. Quick Check:

   Test package = source package + test folder [OK]

Hint: Test package matches source package but in test folder [OK]

Common Mistakes:

• Placing tests in main source folder
• Changing package name for tests
• Putting tests in unrelated packages

3. Given the following project structure:

src/main/java/com/app/utils/Calculator.java
src/test/java/com/app/utils/CalculatorTest.java

What will happen if you run tests only in package com.app.utils?

medium

A. No tests will run because package is incorrect.

B. All tests in the project will run.

C. Only CalculatorTest will run.

D. Tests in other packages will also run.

Solution

1. Step 1: Understand package-based test running

   Running tests in package com.app.utils runs only tests in that package.

2. Step 2: Identify test classes in that package

   CalculatorTest is in com.app.utils, so it will run; tests in other packages won't.

3. Final Answer:

   Only CalculatorTest will run. -> Option C

4. Quick Check:

   Run tests by package runs only that package's tests [OK]

Hint: Run tests by package runs only tests in that package [OK]

Common Mistakes:

• Assuming all tests run regardless of package
• Thinking package name is case-insensitive
• Believing tests outside package run automatically

4. You have a test class com.example.service.OrderServiceTest placed under src/main/java/com/example/service. What is the problem with this setup?

medium

A. Tests should not be placed in the main source folder.

B. Package name is incorrect for tests.

C. Test class name should not end with 'Test'.

D. JUnit does not support tests in com.example.service.

Solution

1. Step 1: Identify source folder for tests

   Tests must be placed under the test source folder, not the main source folder.

2. Step 2: Analyze the given setup

   The test class is in the main source folder, which is incorrect and can cause build or test execution issues.

3. Final Answer:

   Tests should not be placed in the main source folder. -> Option A

4. Quick Check:

   Tests belong in test source folder, not main [OK]

Hint: Tests must be in test source folder, not main source [OK]

Common Mistakes:

• Placing tests in main source folder
• Changing package names unnecessarily
• Misnaming test classes

5. You want to organize tests for a multi-module project where each module has its own source and test folders. How should you organize package-level tests to keep the project clean and maintainable?

hard

A. Place test classes in the same package as source classes within each module's test folder.

B. Put all test classes in a single global test package for the entire project.

C. Place test classes in the main source folder to share with source code.

D. Use different package names for tests to avoid confusion.

Solution

1. Step 1: Understand multi-module project structure

   Each module has separate source and test folders, so tests should mirror source package structure inside each module's test folder.

2. Step 2: Benefits of matching test packages per module

   This keeps tests organized, easy to find, and maintainable per module without mixing unrelated tests.

3. Final Answer:

   Place test classes in the same package as source classes within each module's test folder. -> Option A

4. Quick Check:

   Match test packages to source packages per module [OK]

Hint: Match test packages to source packages inside each module [OK]

Common Mistakes:

• Putting all tests in one global package
• Mixing test and main source folders
• Using different package names for tests