Skip to main content
All Java Snippets Spring JUnit Hibernate 8086
Ankur in JUnit

Mastering JUnit 5 @ExtendWith: The Ultimate Guide to the Jupiter Extension Model

In the evolution of Java testing, the transition from JUnit 4 to JUnit 5 (Jupiter) wasn't just a version bump—it was a complete architectural overhaul. One of the most significant changes was the retirement of the rigid Runner and Rule API in favor of a flexible, modular Extension Model. At the heart of this model lies the @ExtendWith annotation. In this comprehensive guide, we will explore why @ExtendWith is a gateway into a sophisticated ecosystem that boosts developer productivity, how to use it with industry-standard libraries like Mockito, and how to build your own custom extensions to automate repetitive testing logic. What is JUnit 5 @ExtendWith? In JUnit 5, the @ExtendWith annotation is the primary way to register one or more Extensions for a test class or a specific test method. Think of an extension as a "plugin" for your tests. Instead of JUnit being a closed system, it provides Extension Points—specific moments in the test lifecycle (like before a test starts, after it fails, or when a parameter needs to be resolved). The @ExtendWith annotation tells JUnit: "Hey, use this specific class to intercept these lifecycle events for me."

1 min read
Ankur in JUnit

Mastering JUnit 5 @TestTemplate: The Ultimate Guide for Reusable Testing

Have you ever duplicated an entire test class just to run it once with H2, once with PostgreSQL, and once with a mock? Copy–paste works—until it doesn’t. Maintenance explodes, and your original test intent gets buried under a mountain of boilerplate. Testing is the backbone of high-quality software, but as our codebases grow, so does the redundancy in our test suites. While @ParameterizedTest is the go-to for data-driven testing, JUnit 5 offers a more powerful, architectural tool for these scenarios: @TestTemplate. In this guide, we’ll dive deep into how to use @TestTemplate to build flexible, reusable test logic that scales with your application. What is JUnit 5 @TestTemplate? At its core, @TestTemplate is not a test case itself. Instead, it is a blueprint or a container for dynamic test execution. Unlike a standard @Test which runs once, a @TestTemplate is designed to be invoked multiple times based on a set of Invocation Contexts provided by a registered provider. Think of it as a skeleton that gets "fleshed out" by different configurations at runtime.

1 min read
Ankur in JUnit

Mastering JUnit 5 @TestFactory: Dynamic Testing Beyond Parameterized Tests

In the world of Java unit testing, we are mostly accustomed to the standard @Test annotation. These are static tests—their structure and logic are set in stone the moment you compile your code. But anyone who has tried to test rule engines, data migrations, or complex validation pipelines knows the pain: either you duplicate dozens of nearly identical tests or force-fit everything into a parameterized test that eventually becomes unreadable. What if you need to generate hundreds of test cases based on a JSON file, a database result set, or complex runtime logic? Enter Dynamic Testing with JUnit 5. In this comprehensive guide, we’ll explore the @TestFactory annotation, how it differs from traditional testing models, and how to leverage it to make your test suites more flexible, maintainable, and powerful. What is a Dynamic Test? Standard JUnit tests are "fixed." When you write a method annotated with @Test, JUnit knows exactly how many tests exist before the execution starts. A DynamicTest, however, is a test generated during runtime by a factory method. Think of it as the difference between a static HTML page and a React application. One is hardcoded; the other builds its UI based on the data it receives. Dynamic tests allow you to programmatically create a series of tests based on a data source, a list of objects, or even a continuous stream of events.

2 min read
Ankur in JUnit

JUnit 5 with Gradle & Maven: From Setup to Professional Testing

In the modern Java ecosystem, developer productivity is often measured by the speed and reliability of the feedback loop. As a Java developer, two tools you’ll inevitably encounter are Gradle (or Maven) for building your projects and JUnit for testing them. JUnit 5, the latest generation of this popular testing framework, isn't just an incremental update; it’s a complete modular overhaul designed to support modern Java features (like Lambdas) and provide a more robust extension model. Integrating it into your build lifecycle is a fundamental skill. This guide will walk you through the architecture, configuration, and execution of JUnit 5 tests, ensuring your setup is optimized for high-performance development. ⚡ Quick Start: TL;DR Setup If you’re in a hurry or just need a quick reference, here are the essential steps for your build files: Gradle (Groovy) Add Dependencies: junit-jupiter-api (compile) and junit-jupiter-engine (runtime). Enable Platform: Add useJUnitPlatform() inside the test { ... } block. Maven Add Dependency: Include the junit-jupiter aggregator artifact. Plugin Check: Ensure maven-surefire-plugin is version 2.22.0 or higher. A Deep Dive into the JUnit 5 Architecture To configure your build tool correctly, you must first understand that JUnit 5 is a modular framework composed of three main sub-projects. Unlike JUnit 4, which was a monolithic library, JUnit 5 separates concerns to allow for better integration with IDEs and build tools. 1. JUnit Platform This is the core foundation. It defines the TestEngine API, which tools like IntelliJ IDEA, Gradle, and Maven use to discover and launch tests.

2 min read
Ankur in JUnit

The Complete Guide to JUnit 5 @ParameterizedTest: Write Smarter, Faster, and Cleaner Java Tests

Every official way to feed a @ParameterizedTest, built and run against a real JUnit 6.1.3 module: @ValueSource through @ArgumentsSource, how display names actually compile to a MessageFormat pattern, two real anti-patterns caught failing on purpose, and three genuine bugs found by rebuilding this guide's original examples from scratch instead of copying them forward.

2 min read
Ankur in Java

Organising and Displaying JUnit Tests: @DisplayName, @Nested, @Tag (JUnit 5 → JUnit 6)

A beginner-first, fully verified guide to @DisplayName, DisplayNameGenerator, @Nested, and @Tag in JUnit — every code example and console transcript comes from a real Maven module built and run against JUnit 6.1.3, the current GA release verified against Maven Central. Covers what changed for these three annotations between JUnit 5 and JUnit 6, including a real behaviour change (deterministic @Nested ordering) that most migration guides mention only in passing.

2 min read
Ankur in JUnit

JUnit Conditional Test Execution (JUnit 5 → 6)

Run tests only where they belong. Every conditional-execution example from my 2025 article, re-run on JUnit 6.1.3 and JDK 25 with the real skip reasons, what changed from JUnit 5, and where the old text was wrong.

2 min read
Ankur in Java

Dozer Bean Mapping in Java: Practical Guide with Benchmark vs MapStruct

Dozer is a battle-tested Java bean mapper that eliminates DTO-to-entity boilerplate using runtime reflection. This guide covers basic and nested mapping, custom converters, Spring integration, and a head-to-head benchmark vs MapStruct — so you can choose the right tool for your project.

1 min read