82 JUnit interview questions with answers

What they are assessing

Basic orientation.

Model answer

JUnit is the standard unit testing framework for Java, providing annotations to mark test methods, assertions to verify results, and a runner that executes tests and reports outcomes. It is the foundation most Java testing builds on, including integration and automation suites, because build tools and CI systems understand its output natively. The current major version is JUnit 5, which is a complete rewrite rather than an increment on JUnit 4.

What they are assessing

The concept the framework serves.

Model answer

A test of a single unit of behaviour in isolation from its dependencies, which in Java usually means one class or one method, with collaborators replaced by test doubles. The defining properties are that it is fast, deterministic, and fails for exactly one reason, so a failure points directly at the cause. A test that touches a database, the file system or the network is useful but is not a unit test, and calling it one is how suites end up slow and flaky.

Likely follow-up

Why does speed matter so much for unit tests specifically?

What they are assessing

Quality judgement rather than syntax.

Model answer

It verifies one behaviour, so the test name can state what it asserts. It is independent, running correctly alone and in any order. It is deterministic, with no reliance on timing, randomness, the system clock or external state. It is fast enough to run constantly. And it is readable, because a test is also documentation of what the code is supposed to do. The practical test I apply is whether a failing test name tells you what broke without opening the test body.

What they are assessing

Test structure.

Model answer

A convention for structuring a test in three parts: arrange the preconditions and inputs, act by invoking the behaviour under test, and assert the outcome. The value is readability and discipline, since a test with several act steps is usually testing more than one thing. The equivalent given, when, then phrasing comes from BDD and means the same structure. Where a test is hard to split into those three sections, it is normally a signal that the code under test is doing too much.

What they are assessing

The architectural question asked in most JUnit 5 interviews.

Model answer

JUnit Platform, which is the foundation for launching testing frameworks on the JVM and defines the TestEngine API that build tools and IDEs integrate with. JUnit Jupiter, which is the new programming and extension model, meaning the annotations and assertions you actually write against. And JUnit Vintage, a TestEngine that runs JUnit 3 and JUnit 4 tests on the platform. The separation is what allows a project to run JUnit 4 and JUnit 5 tests side by side during a migration.

Likely follow-up

Which of the three would you add to a project that is migrating gradually?

What they are assessing

Understanding of the motivation, which explains the design.

Model answer

JUnit 4 was a single jar with a monolithic design, and its extension points were limited and mutually exclusive: a test class could have only one Runner, so you could not combine Spring and Mockito runners without workarounds. Rules improved this but did not fully solve it. JUnit 5 separated the platform from the programming model so other frameworks can run on the same infrastructure, and replaced runners and rules with a single composable extension model where many extensions coexist. It also required Java 8 so it could use lambdas, which is why assertThrows and assertAll are possible at all.

What they are assessing

Practical setup knowledge.

Model answer

junit-jupiter-api for compiling tests, junit-jupiter-engine at runtime to execute them, and junit-jupiter-params for parameterized tests. The aggregate junit-jupiter artefact pulls in all three, which is the usual choice. junit-vintage-engine is added only if JUnit 4 tests must also run. The common failure is having only the api on the classpath, which compiles fine and then reports no tests found, because nothing is present to execute them.

Trap to avoid

Declaring only junit-jupiter-api. The project compiles, the build is green, and zero tests run.

What they are assessing

Core vocabulary.

Model answer

At Test marks a test method. BeforeEach and AfterEach run before and after every test method. BeforeAll and AfterAll run once before and after all tests in the class, and must be static unless the test instance lifecycle is per class. Disabled skips a test or class. Those five cover most of what a suite uses day to day.

What they are assessing

Execution order, asked frequently.

Model answer

BeforeAll once, then for each test method BeforeEach, the test, then AfterEach, and finally AfterAll once at the end. With nested classes the outer BeforeEach methods run before the inner ones, and the AfterEach methods unwind in the opposite order. Extensions registered on the class also participate, running their callbacks around these in a defined order.

What they are assessing

Understanding of the instance model behind the annotation.

Model answer

Because by default JUnit creates a new instance of the test class for each test method, so there is no single instance for a once-per-class method to belong to. Making it static means it belongs to the class rather than an instance. The exception is when the class is annotated with TestInstance set to per class lifecycle, where one instance serves all tests and BeforeAll can then be an instance method. This connection between the two features is what the question is really checking.

Likely follow-up

What changes when you set the test instance lifecycle to per class?

What they are assessing

Selective execution.

Model answer

It labels a test or class so it can be included or excluded at execution time. Tags are filtered through the build tool, with Surefire exposing groups and excludedGroups parameters, or through the platform launcher directly. Typical uses are marking a fast subset for commit builds, separating slow or integration tests, or isolating tests that need a particular environment. It replaces the Category annotation from JUnit 4 and is considerably simpler to use.

What they are assessing

A practical guard.

Model answer

It fails a test if it exceeds a given duration, and can be applied to a method, a class, or globally through a configuration property. It is useful as a safety net against a test hanging and blocking the build, particularly where the code under test involves waiting or external calls. It is not a performance assertion, and using it as one produces intermittent failures on a loaded CI agent, which is the common misuse.

Trap to avoid

Using Timeout to assert performance. CI agents vary enough that it becomes a flaky test rather than a meaningful measurement.

What they are assessing

A composability feature that is genuinely useful.

Model answer

JUnit 5 annotations can be used to compose custom annotations, so you can define a single annotation that carries Tag, Test and whatever else you need, and apply it in one place. The practical use is removing repetition: rather than annotating forty tests with the same three annotations, you define one meaningful annotation such as a slow integration test marker and use it. It also centralises the definition, so changing what that category means is a one-line change.

What they are assessing

Basic API knowledge.

Model answer

assertEquals and assertNotEquals, assertTrue and assertFalse, assertNull and assertNotNull, assertSame and assertNotSame for reference identity, assertArrayEquals and assertIterableEquals for collections, assertThrows and assertDoesNotThrow for exceptions, assertAll for grouping, and assertTimeout for duration. All are static methods on Assertions, and all accept an optional message or message supplier as the final argument.

What they are assessing

A difference from JUnit 4 that candidates often answer with the old approach.

Model answer

With assertThrows, passing the expected exception type and a lambda invoking the code. It returns the thrown exception, so you can then assert on its message or its cause, which is the significant improvement. In JUnit 4 the equivalent was the expected attribute on the Test annotation, which could not assert on the message and, worse, passed if the exception was thrown anywhere in the method rather than at the specific call you intended.

Likely follow-up

Why was the JUnit 4 expected attribute considered unsafe?

What they are assessing

Grouped assertion behaviour.

Model answer

It takes several assertions as lambdas and executes all of them regardless of which fail, reporting every failure together rather than stopping at the first. It is useful when verifying several properties of one outcome, such as the fields of a returned object, because a single run then tells you all three fields are wrong rather than only the first. It is the closest JUnit has to soft assertions, and the right use is assertions about one logical outcome rather than unrelated checks bundled into one test.

What they are assessing

A distinction with real consequences in Java.

Model answer

assertEquals compares using the equals method, so two distinct objects with the same content pass. assertSame compares references, so it passes only if both arguments are literally the same object. assertEquals is almost always what you want, and assertSame is for cases where identity genuinely matters, such as verifying a cache returned the same instance. The related trap is asserting equality on a class that does not override equals, where assertEquals falls back to reference comparison and fails confusingly.

What they are assessing

Tooling preference with a reason.

Model answer

AssertJ for most work, because the fluent API reads better and the failure messages are substantially more informative, particularly for collections and object comparison where JUnit will tell you two lists differ and AssertJ will tell you how. It also makes complex assertions readable without helper methods. JUnit assertions remain fine for simple cases and have no extra dependency. What I would avoid is mixing three assertion libraries in one codebase, since inconsistent style makes tests harder to read than any single choice.

Likely follow-up

What does AssertJ give you for collection assertions that JUnit does not?

What they are assessing

Diagnostic quality.

Model answer

Because the failure output is what someone reads at eight in the morning when CI is red, and expected true but was false tells them nothing. A message should say what the assertion was checking, not restate the code. JUnit also accepts a supplier rather than a string, which defers construction so an expensive message is only built when the assertion fails. The better alternative where possible is an assertion library whose default messages are already informative, which removes the need for most custom messages.

What they are assessing

A design decision with implications for test independence.

Model answer

Per method, meaning JUnit creates a fresh instance of the test class for every test method. The purpose is isolation: instance fields are reset between tests, so one test cannot leave state that affects another. The alternative, set with TestInstance and the per class lifecycle, creates one instance for all tests in the class, which allows non-static BeforeAll and shared state but reintroduces the coupling the default prevents.

What they are assessing

Judgement about when to give up isolation.

Model answer

When setup is genuinely expensive and shared, such as starting a container or a server once for a class of integration tests, and when per class state is otherwise awkward. It also lets BeforeAll be an instance method, which is more convenient. The cost is that instance state persists across tests, so a test can be affected by what ran before it, and it is required for ordered tests that build on each other, which is itself a pattern I would avoid. I would use it deliberately for expensive setup, not for convenience.

Trap to avoid

Switching to per class because a static BeforeAll is inconvenient. It silently removes the isolation that keeps tests independent.

What they are assessing

Cleanup reliability.

Model answer

Yes. AfterEach runs regardless of whether the test passed, failed or threw, which is why cleanup belongs there rather than at the end of the test body. If an AfterEach method itself throws, the test is reported as failed even when the body passed, and when several AfterEach methods exist they all run even if an earlier one fails. The exception worth knowing is that if BeforeEach throws, the test method does not run but AfterEach still does, which can surprise cleanup code that assumes setup completed.

Likely follow-up

What happens if BeforeEach throws an exception?

What they are assessing

A practical problem the lifecycle annotations do not solve.

Model answer

Not with BeforeAll, which is per class. The JUnit 5 answer is an extension implementing BeforeAllCallback combined with the extension context store at root scope, so initialisation happens once per launch and is reused, with CloseableResource for teardown at the end of the run. Libraries such as Testcontainers use exactly this mechanism for singleton containers. The alternative in Spring projects is the test application context, which is cached and reused across classes with the same configuration.

What they are assessing

A core JUnit 5 feature.

Model answer

A test executed several times with different arguments, declared with ParameterizedTest instead of Test, plus a source annotation supplying the values. Each invocation is reported as a separate test, so one failing input does not hide the others. It needs the junit-jupiter-params artefact on the classpath, which is a common omission since the annotations do not resolve without it.

What they are assessing

Breadth of the feature.

Model answer

ValueSource for a simple array of literals of one type. CsvSource for inline rows of several values. CsvFileSource for the same from a file. MethodSource for a static method returning a Stream of arguments, which is the most flexible. EnumSource for enum constants with include and exclude filters. ArgumentsSource for a custom provider. Plus NullSource, EmptySource and NullAndEmptySource, which are worth knowing because they cover the two inputs most likely to be forgotten.

Likely follow-up

When would you choose MethodSource over CsvSource?

What they are assessing

Judgement rather than feature knowledge.

Model answer

When the cases differ in behaviour rather than only in data. If each row needs a different expected outcome shape, or the test body contains conditionals branching on the input, the cases are different tests wearing a shared body and should be separated. Parameterized tests are right where one rule is being verified across many inputs, such as validation boundaries. They are also poor when the parameters make the test unreadable, since a row of eight values tells a reader nothing about what is being tested.

What they are assessing

A related feature with a narrow purpose.

Model answer

It runs the same test a specified number of times, with RepetitionInfo available as a parameter if the test needs to know which repetition it is in. It is useful for exercising something with inherent randomness, or for confirming a test is genuinely deterministic before trusting it. What it is not is a substitute for a parameterized test, and running a test a hundred times to reduce flakiness is treating a symptom rather than the cause.

What they are assessing

A less commonly used feature that distinguishes depth.

Model answer

A dynamic test is generated at runtime by a method annotated with TestFactory, returning a stream or collection of DynamicTest instances each with a display name and an executable. The difference is timing: parameterized test arguments are resolved at discovery time, while dynamic tests are created during execution, so the set of tests can depend on data not available beforehand, such as the contents of a directory or a response from a service. The trade-off is that dynamic tests do not support the usual lifecycle callbacks per generated test.

What they are assessing

A distinction with a meaningful consequence.

Model answer

An assumption states a precondition for the test to be meaningful. If it does not hold, the test is aborted and reported as skipped rather than failed. An assertion states what the code should do, and failing it means a defect. The methods are assumeTrue, assumeFalse and assumingThat. The point is reporting accuracy: a test that cannot run because an environment is unavailable is not a failure, and marking it as one trains people to ignore red builds.

Likely follow-up

What is the risk of overusing assumptions?

What they are assessing

Balance.

Model answer

That tests silently stop running and nobody notices, because skipped is not red. A suite where a third of the tests are aborted on an environment condition reports green while providing a fraction of the coverage anyone believes it has. So assumptions are appropriate where the condition is genuinely legitimate, such as a platform-specific test, and the mitigation is to monitor skip counts rather than only failures. Where the condition is an environment that should be available, the right fix is the environment.

What they are assessing

A declarative alternative to assumptions.

Model answer

EnabledOnOs and DisabledOnOs, EnabledOnJre and the range variants, EnabledIfSystemProperty, EnabledIfEnvironmentVariable, and EnabledIf with a custom condition method. They are generally cleaner than assumptions because the condition is visible at the declaration rather than buried in the test body, and the test is reported as disabled with a reason. Behind them is the ExecutionCondition extension point, which you can implement for anything the built-in annotations do not cover.

What they are assessing

Test organisation.

Model answer

It marks an inner non-static class as a nested test class, so related tests can be grouped with their own BeforeEach setup while still inheriting the outer class setup. The usual pattern is a nested class per scenario or per state, such as when the account is overdrawn, with the shared setup for that state in its own BeforeEach. It produces a readable hierarchy in the test report and removes the repetition of setting up the same precondition in every test.

Likely follow-up

Why must a nested test class be non-static?

What they are assessing

Readability.

Model answer

It supplies a human readable name for a test class or method, shown in reports and IDEs instead of the method name, and it accepts spaces, punctuation and emoji. It is worth using because the report is read by people who did not write the test, and a sentence stating the expected behaviour is far more useful than a camel case method name. There is also DisplayNameGenerator for applying a convention across a whole suite, such as converting method names to sentences, which avoids annotating every method.

What they are assessing

A small practice with a large effect on suite usefulness.

Model answer

So that the name alone states the behaviour and the condition, because the name is what appears in a failure report. Conventions vary, with method under test, scenario, expected outcome being common, or a plain sentence such as returns zero when the basket is empty. What matters is that someone reading a CI failure can tell what broke without opening the file. Names like testCase1 or testLogin fail that standard, and in a suite of two thousand tests the cumulative cost is substantial.

What they are assessing

The replacement for runners and rules.

Model answer

A single mechanism for extending test behaviour, replacing JUnit 4 runners and rules. An extension implements one or more callback interfaces and is registered with ExtendWith on a class or method, or RegisterExtension on a field for programmatic configuration. The key improvement over JUnit 4 is composability: a class can use many extensions at once, where JUnit 4 allowed only one runner, which was the reason combining Spring and Mockito needed workarounds.

What they are assessing

Depth on the extension model.

Model answer

Lifecycle callbacks: BeforeAllCallback, BeforeEachCallback, BeforeTestExecutionCallback and their after counterparts. ParameterResolver, for injecting arguments into constructors and test methods. ExecutionCondition, for deciding whether a test runs. TestExecutionExceptionHandler, for intercepting failures. TestInstancePostProcessor, for acting on the created instance. TestWatcher, for observing outcomes, which is how reporting integrations hook in. And InvocationInterceptor for wrapping the invocation itself.

Likely follow-up

Which would you implement to take a screenshot on failure?

What they are assessing

Applying the extension model to a practical automation need.

Model answer

With TestWatcher, implementing testFailed, which receives the extension context and the cause. The extension needs access to the driver, which is usually obtained from the extension context store where a BeforeEach callback placed it, so the driver lifecycle and the screenshot capture live in the same extension. Registering it with ExtendWith on a base class means every UI test gets it without repetition. TestExecutionExceptionHandler is an alternative but is more intrusive, because it can swallow the exception, whereas TestWatcher only observes.

What they are assessing

State management for extensions.

Model answer

A namespaced key-value store on the extension context, used to pass state between extension callbacks and into tests without static fields. It is scoped, so a value stored at method level is discarded after the test while one stored at root level persists for the whole launch, which is the mechanism for sharing expensive setup across classes. Storing a value implementing CloseableResource means its close method is called when that scope ends, which is how container and connection cleanup is handled reliably.

What they are assessing

Dependency injection in tests.

Model answer

An extension point allowing arguments to be injected into test constructors and methods. JUnit itself provides resolvers for TestInfo, which gives the display name and tags, TestReporter for publishing entries into the report, and RepetitionInfo for repeated tests. Frameworks use it extensively: the Mockito extension injects mocks, and Spring injects beans. Writing one is the clean way to supply a configured object to every test without a base class or a static holder.

What they are assessing

The concept behind the library.

Model answer

Replacing a real dependency with a controlled substitute so the unit under test can be tested in isolation. It is needed because real dependencies make tests slow, non-deterministic and dependent on external state, and because some conditions cannot be produced on demand, such as a service returning an error or a timeout. Mocking lets you specify what the collaborator returns and then verify how it was called, which is often the behaviour you actually care about.

What they are assessing

Vocabulary candidates frequently blur.

Model answer

A stub supplies canned responses so the test can proceed, with no assertion on how it was used. A mock additionally has expectations about the interaction, so the test verifies it was called correctly. A spy wraps a real object, delegating to the real implementation except where specifically overridden, which is useful for partial substitution of a class you mostly want to run for real. In Mockito, mock and spy are distinct factory methods and stubbing is what you do to either with when and thenReturn.

Likely follow-up

When would a spy be the right choice rather than a mock?

What they are assessing

Practical setup.

Model answer

With MockitoExtension, registered through ExtendWith, which processes the Mock and InjectMocks annotations and validates the stubbing after each test. That validation is worth noting: by default it fails the test on unnecessary stubbing, meaning a when clause that was never used, which catches tests that have drifted from the code they claim to verify. The alternative is calling openMocks explicitly in BeforeEach, which is what you do when the extension cannot be used.

What they are assessing

Judgement about a technique that is easy to overuse.

Model answer

Tests that verify the implementation rather than the behaviour, so they break whenever the code is refactored even though nothing is actually wrong. A test asserting that three specific collaborators were called in a specific order is coupled to the current design, and it will fail on a correct refactoring, which teaches the team that failing tests mean the test is wrong. The other risk is that everything passes while the integration is broken, since every boundary has been replaced by an assumption nobody verified. The corrective is fewer mocks, more real collaborators where they are cheap, and contract tests at the boundaries.

Trap to avoid

Treating high mock usage as good isolation. Past a point it means the tests describe the code structure rather than its behaviour.

What they are assessing

A specific Mockito feature with a clear purpose.

Model answer

It captures the argument passed to a mocked method so the test can assert on it afterwards. You use it when the argument is constructed inside the code under test and is not available to the test directly, such as an event object or a request built from several inputs. It is more flexible than matching with an argument matcher, because you can make several detailed assertions on the captured object rather than expressing everything as a single match condition.

What they are assessing

Migration knowledge, needed because both versions coexist everywhere.

Model answer

Before becomes BeforeEach, After becomes AfterEach, BeforeClass becomes BeforeAll, AfterClass becomes AfterAll, Ignore becomes Disabled, Category becomes Tag, and RunWith becomes ExtendWith. The Test annotation keeps its name but moves package and loses its expected and timeout attributes, which become assertThrows and the Timeout annotation. The package change is the detail that bites, since an unchanged import silently keeps the test on JUnit 4 if Vintage is present.

Trap to avoid

Leaving a JUnit 4 import in place. With the Vintage engine on the classpath the test still runs, so nothing fails, and the class quietly never migrated.

What they are assessing

Migration strategy rather than syntax.

Model answer

Incrementally, using the Vintage engine so both run side by side and nothing has to be converted in one change. New tests are written in JUnit 5 immediately, which stops the problem growing. Existing tests migrate when they are being touched for another reason, and in bulk only where a mechanical conversion is safe, since IDE assistance handles the annotation renames reliably. The parts needing real work are rules and runners, which have no direct equivalent and must be rewritten as extensions. I would also set a point at which Vintage is removed, since otherwise the migration never finishes.

Likely follow-up

Which JUnit 4 constructs have no direct JUnit 5 equivalent?

What they are assessing

The construct that makes migration non-mechanical.

Model answer

Extensions. A rule wrapping test execution becomes a combination of before and after callbacks, or InvocationInterceptor where the wrapping is genuinely needed. Common rules have direct replacements: TemporaryFolder becomes the TempDir annotation, ExpectedException becomes assertThrows, and Timeout becomes the Timeout annotation. For third party rules, many libraries now ship a JUnit 5 extension, and junit-jupiter-migrationsupport can run some rules under Jupiter as an interim measure.

What they are assessing

A practical setup detail that blocks people.

Model answer

Surefire version 2.22.0 or later, which supports the JUnit Platform natively, plus the Jupiter engine on the test classpath. Older Surefire versions do not discover JUnit 5 tests at all and report zero tests without any error, which is the symptom people hit. Naming conventions still apply, so a class not matching the Surefire include patterns is never discovered regardless of version.

What they are assessing

Selective execution in practice.

Model answer

With Surefire, through the groups and excludedGroups parameters, which accept tag expressions including and, or and not. Those can be driven by a property so the tag is chosen per invocation, which is how a pipeline runs a fast subset on commit and everything on a schedule. The platform also supports tag filtering directly through the launcher and the console launcher, which is what IDEs and other tools use.

What they are assessing

Configuration beyond annotations.

Model answer

A properties file on the test classpath holding platform configuration: enabling parallel execution and its strategy, setting the default test instance lifecycle, configuring the display name generator, and setting the default timeout. It is the right place for settings that should apply across the whole suite rather than being annotated per class. Being on the classpath rather than in the build file means it applies consistently however the tests are launched, including from an IDE.

What they are assessing

A feature with real prerequisites.

Model answer

By enabling it in junit-platform.properties with the parallel execution enabled property, then setting the default execution mode to concurrent, or annotating specific classes with Execution. The parallelism strategy is configurable as dynamic, fixed or custom. The prerequisite is that the tests are genuinely independent, because parallelising a suite with shared static state produces intermittent failures that look like product defects, and the time spent diagnosing those usually exceeds the time saved.

Likely follow-up

How would you handle a test that cannot run concurrently with another?

What they are assessing

Managing contention in a parallel suite.

Model answer

An annotation declaring that a test needs access to a named resource, with read or read-write mode, so the platform serialises tests that would otherwise conflict. The canonical use is a shared mutable resource such as a system property, an environment variable or a shared file. It lets most of the suite run concurrently while the few genuinely conflicting tests are ordered, which is better than disabling parallelism entirely because a handful of tests share state.

What they are assessing

Diagnostic knowledge.

Model answer

Shared mutable static state, which is the most common cause. Reliance on system properties or environment variables that another test modifies. A shared database or file that tests write to without isolation, particularly fixed record identifiers. Singletons holding state between tests. Ordering assumptions, where a test depends on another having run first. And anything binding a fixed port. The diagnostic is that failures appear intermittently and move around, rather than one test failing consistently.

What they are assessing

Test code quality.

Model answer

Generally not. A conditional means the test takes different paths depending on something, so a passing result does not tell you which path ran, and the branch that is never taken is dead code masquerading as coverage. A loop usually indicates a parameterized test would be clearer, and it stops at the first failure so you learn about one bad input rather than all of them. Test code should be the simplest code in the repository, because a test with logic in it needs testing itself.

Likely follow-up

What should replace a loop over input values in a test?

What they are assessing

A design question with a defensible answer either way.

Model answer

One logical verification, which is not the same as one assertion statement. Asserting on several fields of a single returned object is one verification and is fine, ideally grouped with assertAll so all failures are reported. What should not happen is a test verifying creation, then notification, then an inventory update, because when it fails you do not know which part broke and the later checks never execute. The practical rule is that the test name should describe what is asserted, and if the name needs an and, it is probably two tests.

What they are assessing

A principle with a specific JUnit feature behind it.

Model answer

No. JUnit deliberately does not guarantee method order by default, precisely to prevent that dependency. TestMethodOrder with the Order annotation exists and is occasionally legitimate, such as for a reporting sequence or a documented integration scenario, but ordered tests cannot be run individually, cannot be parallelised, and produce failures that point at the wrong test. When a test needs state from a previous one, the right fix is for it to establish its own preconditions, usually through a helper rather than through the user interface or the slow path.

Trap to avoid

Using Order to make a broken suite pass. It converts a test independence defect into a permanent constraint on how the suite can run.

What they are assessing

A metric that is routinely misused.

Model answer

The proportion of code executed by the test suite, measured by tools such as JaCoCo, usually reported as line or branch coverage. It is useful as a gap finder: zero coverage on a class tells you something real. It is poor as a target, because coverage measures execution rather than verification, so a test calling every method and asserting nothing reaches a high number while proving nothing. Branch coverage is more informative than line coverage, and mutation testing is the stronger signal if the team is willing to run it.

Likely follow-up

What does mutation testing tell you that coverage does not?

What they are assessing

Discipline rather than tolerance.

Model answer

Investigate rather than rerun, because the default response of rerunning until green is how a suite loses credibility. In unit tests specifically, the causes are narrow: dependence on the system clock, randomness without a fixed seed, shared static state between tests, ordering assumptions, or genuine concurrency in the code under test. The last is the valuable case, because an intermittently failing test over concurrent code is usually revealing a real race. If it cannot be fixed immediately, disable it with a reason and an owner rather than leaving it to erode trust in every other result.

What they are assessing

A small change from JUnit 4 that is frequently asked.

Model answer

No. JUnit 5 discovers package-private methods, so test methods and classes do not need the public modifier, which JUnit 4 required. Package-private is the convention in JUnit 5 because tests are not an API for anything outside their package. They must not be private or static, which are the two modifiers that genuinely prevent discovery.

What they are assessing

A specific and common testability problem.

Model answer

By making the clock injectable rather than reading it directly. In modern Java that means taking a Clock as a dependency and using Clock.fixed in tests, which gives a deterministic now without any mocking framework. Where the code calls a static time method directly, it needs refactoring, which is the right outcome since untestable time handling is a design problem. Mocking static calls is possible with Mockito inline but I would treat it as a last resort for code I cannot change, because it hides the design issue rather than fixing it.

What they are assessing

A practice frequently conflated with the tool.

Model answer

Test driven development is writing a failing test first, making it pass with the simplest code, then refactoring, repeating in short cycles. It does not require JUnit specifically, though in Java JUnit is what you would use. The point worth making is that TDD is a design practice as much as a testing one: writing the test first forces you to decide the interface before the implementation, which is why TDD code tends to be more testable. Having a JUnit suite does not mean a team practises TDD, and the two are frequently conflated in interviews.

What they are assessing

A useful built-in that replaces a JUnit 4 rule.

Model answer

An annotation that injects a temporary directory into a test or field, created before use and deleted afterwards by JUnit. It replaces the JUnit 4 TemporaryFolder rule. It is better than creating files manually because cleanup is guaranteed even when the test fails, each test gets an isolated directory so parallel execution is safe, and there is no risk of tests colliding on a fixed path, which is a classic cause of intermittent failures on CI where several builds share an agent.

What they are assessing

A common practical need.

Model answer

JUnit provides assertIterableEquals for ordered equality and assertArrayEquals for arrays, but both are blunt: they tell you the collections differ without saying how. For anything beyond trivial cases an assertion library is substantially better, since AssertJ can assert containment, order independence, subset relationships and element properties with messages that identify the specific difference. The thing to avoid is asserting on size and then indexing into the collection, which produces an IndexOutOfBoundsException rather than a useful assertion failure when the size is wrong.

What they are assessing

A behaviour that surprises people migrating.

Model answer

With MockitoExtension the default strictness fails a test that declares a stubbing never used, and reports argument mismatches explicitly. It exists because unused stubbing almost always means the test has drifted from the code: either the production code no longer makes that call, or the arguments changed and the stub silently stopped matching, leaving the mock returning null. Without strictness those produce confusing null pointer failures elsewhere. It can be relaxed per test with MockitoSettings, which is occasionally justified and usually a sign the test should be simplified.

Likely follow-up

What happens when a stubbing silently stops matching?

What they are assessing

A very common setup failure.

Model answer

Surefire older than 2.22.0, which cannot discover JUnit Platform tests. Only junit-jupiter-api on the classpath with no engine, so nothing can execute them. Test class names not matching the Surefire include patterns, which is silent rather than reported. A JUnit 4 import left in place with no Vintage engine present. Or tests in the wrong source directory. The important point is that all of these produce a green build with no tests executed, which is worse than a failure because it reports success.

What they are assessing

Maintainability, where tests are often neglected.

Model answer

Through object mothers or test data builders that construct valid domain objects with sensible defaults and allow overriding the fields a given test cares about, which removes long repetitive setup and makes each test state only what matters to it. Custom assertions for domain concepts that are asserted repeatedly. Extensions for cross-cutting setup rather than base classes, since deep inheritance in test classes becomes hard to follow. The one I would avoid is a large abstract base class accumulating helper methods, which is the most common approach and the hardest to untangle later.

What they are assessing

Organisation in practice.

Model answer

With nested classes grouping tests by the scenario or state they share, each carrying its own BeforeEach for that state. So a payment service might have a nested class for when the account has sufficient funds, another for insufficient funds, and another for a closed account, with the tests inside each covering the variations. The result reads as a specification, removes repeated setup, and gives a report structure that makes a failure easy to locate. DisplayName on each nested class makes the output read as sentences.

What they are assessing

A detail that matters when several extensions are in use.

Model answer

Extensions registered declaratively are applied in declaration order, with before callbacks running in that order and after callbacks in reverse, which gives proper nesting. Extensions inherited from a superclass or an enclosing class run before those declared on the class itself. Programmatic extensions registered with RegisterExtension can control relative order with the Order annotation. The reason it matters is that an extension establishing state must run before one that consumes it, and getting that wrong produces a null at test time rather than a clear error.

What they are assessing

Scope separation.

Model answer

Unit tests isolate a single unit with collaborators replaced, run in milliseconds, and need no external infrastructure. Integration tests exercise several components together, often with a real database or a container, and are slower and more environment-dependent. Practically they are separated by naming convention and by tag, so Surefire runs the unit tests in the test phase and Failsafe runs the integration tests in the integration-test phase. Keeping them separate matters because mixing them makes the fast feedback loop slow, which is the main reason developers stop running tests locally.

What they are assessing

Review judgement.

Model answer

Whether the test name states the behaviour. Whether it asserts anything meaningful, since a test that calls a method and asserts no exception is very common and nearly worthless. Whether it would fail if the production code were broken, which is the single most useful question. Whether it is independent of order and of other tests. Whether it tests behaviour or implementation, since heavy verification of interactions means it will break on refactoring. And whether the setup is comprehensible, because a test nobody can read will not be maintained.

Likely follow-up

How do you check that a test would actually fail if the code were broken?

What they are assessing

Report readability.

Model answer

Through the name attribute on ParameterizedTest, which supports placeholders for the invocation index and the arguments, including individual arguments by position. Without it the report shows generic invocation numbers, so a failure tells you case four failed without saying what case four was. With a well chosen pattern the report reads as a list of cases and their outcomes, which is the difference between a parameterized test that documents behaviour and one that obscures it.

What they are assessing

Two ways to not run a test.

Model answer

Disabled is unconditional and static: the test never runs until someone removes the annotation, and it should carry a reason explaining why. An assumption is evaluated at runtime, so the test runs when the condition holds and is aborted otherwise. Disabled is appropriate for a test temporarily out of action with a known issue, and the reason string matters because otherwise nobody knows whether it is safe to re-enable. An assumption is appropriate when the condition is environmental and legitimate.

What they are assessing

A practical migration question.

Model answer

Yes, with the Vintage engine on the classpath alongside the Jupiter engine, and both JUnit 4 and JUnit 5 dependencies present. Surefire discovers and runs both, reporting them together. This is the intended migration path and it works well. The risk is complacency: with both engines present there is no pressure to finish, and projects sit in this state for years, which means new contributors have to know two frameworks and the inconsistency compounds. Setting a date to remove Vintage is what makes it a migration rather than a permanent arrangement.

What they are assessing

Judgement about mocking boundaries.

Model answer

Value objects and simple data structures, which should just be constructed, since mocking them adds noise and no isolation. Types you do not own, because a mock encodes your assumption about a third party API and will not notice when that assumption becomes wrong, so a thin wrapper you do own is the better seam. And the class under test itself, beyond a spy for a specific partial case, since mocking what you are testing means the test verifies a mock. The general rule is to mock at the architectural boundaries rather than between every pair of classes.

What they are assessing

Practical optimisation.

Model answer

Separate unit tests from integration tests so the fast suite can run in seconds, which is the biggest single win and the one most teams have not done. Remove external dependencies from unit tests, since a test hitting a database is the main source of slowness. Enable parallel execution once the tests are independent. Share expensive fixtures through an extension at root scope rather than per class. And measure rather than guess, since the duration is almost always concentrated in a small number of tests that can be fixed individually.

What they are assessing

A small question that reveals understanding of the instance model.

Model answer

Either works with the default per method lifecycle, since a new instance is created for each test and the constructor therefore runs per test. BeforeEach is conventional and clearer, because it states the intent and because a constructor cannot easily be split across inherited behaviour. The constructor does have one advantage, which is that it can take injected parameters through a ParameterResolver, so frameworks supplying dependencies often use constructor injection. Mixing both for the same purpose in one class is what makes a test class confusing.

What they are assessing

Strategy rather than technique.

Model answer

Unit test where the logic is, meaning calculation, branching, validation and transformation, because those have many cases and the cases are cheap to cover at that level. Leave to integration or higher the wiring, the configuration, and anything whose risk is that the pieces do not fit together, since a unit test of a class with mocked collaborators proves nothing about that. I would also not unit test trivial accessors or code that only delegates, since those tests cost maintenance and would never fail for a reason that matters.

What they are assessing

Where unit tests sit in the broader strategy.

Model answer

The model says many fast unit tests, fewer integration tests and a small number of end to end tests, because cost and fragility rise with scope. JUnit serves the bottom two layers directly and is often the runner for the top layer as well, since Selenium and REST Assured suites are usually executed through it. The point worth making is that using JUnit does not mean writing unit tests: a JUnit suite full of tests that start a browser is an inverted pyramid wearing the right annotations.

What they are assessing

Diagnosing a common and misleading situation.

Model answer

Whether the tests assert anything, since coverage measures execution and a suite that calls methods without meaningful assertions reaches a high number while verifying little. Then whether the coverage is in the right places, because eighty percent overall can mean the trivial code is fully covered and the complex branching is not, which branch coverage rather than line coverage reveals. Then where the escaping defects actually originate, since if they are integration or requirement defects, no amount of unit coverage would have caught them. Mutation testing is the most direct way to answer the first question if the team will run it.

Likely follow-up

What would change your mind that the problem is the tests rather than the strategy?

What they are assessing

Influence and culture.

Model answer

By making the suite worth maintaining first, because a slow, flaky suite will be neglected regardless of policy. That means fixing the speed and the flakiness before asking for discipline. Then making tests part of the definition of done rather than a follow-up task, so they are written with the code. Then reviewing test code with the same attention as production code, since a team that reviews one and skims the other is communicating what it values. And treating a red build as a stop-the-line event, because the moment people start ignoring red, nothing else holds.

What they are assessing

Depth on the architecture.

Model answer

The API for discovering and executing tests programmatically, which build tools, IDEs and the console launcher use rather than invoking test classes directly. It takes a discovery request with selectors and filters, returns a test plan, and executes it with listeners receiving events. It matters because it is the integration point: anything that needs to run tests and observe results, including custom reporting and test selection tooling, hooks in here rather than depending on Jupiter. It is also why other frameworks can run on the platform alongside JUnit.

What they are assessing

A closing question revealing depth of experience.

Model answer

Tests that cannot fail. A method is called, no meaningful assertion is made, coverage goes up and the suite proves nothing, which is worse than no test because it creates confidence. Close behind are tests coupled to implementation through heavy mock verification, which break on every refactoring until the team concludes that failing tests mean the test is wrong, and suites where unit and integration tests are mixed so the fast feedback loop is gone and developers stop running them locally. All three produce a green build that nobody actually relies on, which is the real failure.