@ankurm

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.

Ankur in JUnit

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

Here's a pattern I've seen on almost every Java team I've worked with: a developer writes a clean test for a validation method. Two weeks later, a bug is found with a different input. They copy-paste the test, change two values, rename it testValidate_withNull. A month later there are eight copies, each testing the same two lines of logic with slightly different inputs. This is test bloat. It's not just an aesthetic problem — it's a maintenance trap. When the method signature changes, you're updating eight tests instead of one. When a new edge case surfaces, do you add a ninth copy or finally refactor? @ParameterizedTest is JUnit 5's answer to this. One method, many inputs, full per-invocation reporting in your IDE and CI pipeline. This guide covers every source annotation with working examples, and shows you exactly which one to reach for in each situation.

Ankur in JUnit

Master JUnit 5: How to Organize and Display Your Tests Like a Pro

As software systems grow in complexity, a flat list of hundreds of test cases becomes a nightmare to maintain. If you’ve ever found yourself scrolling through a wall of testMethod123() trying to figure out what actually failed, this guide is for you. In this post, we’ll explore how JUnit 5 (Jupiter) transforms test suites from messy codebases into well-documented, hierarchical, and searchable assets using four powerhouse annotations: @DisplayName, @Nested, @Tag, and @Disabled. Executive Summary: Key Takeaways If you're in a hurry, here is the TL;DR version of how to organize your JUnit 5 test suite: @DisplayName – Replace cryptic method names with human‑readable descriptions. @Nested – Group related tests into hierarchical inner classes for better structure and shared setup. @Tag – Categorize tests (for example, fast, smoke, integration) to run specific subsets in CI/CD pipelines. @Disabled – Formally skip tests with a documented reason instead of commenting code out. 1. Human-Readable Reports with @DisplayName By default, JUnit uses the method or class name as the display name. While camelCase is great for compilers, it’s not ideal for humans, QA engineers, or stakeholders reading test reports.

Ankur in JUnit

Mastering JUnit 5 Conditional Execution: Build Smarter, Environment-Aware Tests

In the high-speed world of modern DevOps and CI/CD, the "one size fits all" philosophy is a relic of the past. As architectures move toward microservices and multi-cloud environments, your testing strategy must adapt. You might have a test suite that interacts with a Windows-specific DLL, a legacy integration that requires Java 8, or a performance benchmark that only makes sense on high-spec production-like runners. Running these tests in the wrong environment doesn't just lead to confusing failure logs; it creates "noise," increases build times, and erodes trust in your automation. This is where JUnit 5 Conditional Execution shines. Unlike the blunt @Disabled annotation, JUnit 5 (Jupiter) provides a sophisticated toolkit to programmatically enable or disable tests based on the runtime context. In this comprehensive guide, we’ll explore the standard annotations and dive into advanced custom conditions to make your test suite truly environment-aware. 1. Operating System Conditions: Target Your Infrastructure Operating systems handle file systems, networking stacks, and native libraries differently. If your code uses Runtime.exec() or accesses specific paths like C:\Windows\System32, running that test on a Linux build server is a guaranteed failure.

Ankur in JUnit

JUnit 5 @AfterAll: One-Time Teardown for Your Tests

In the world of automated testing, we often talk about the "Arrange-Act-Assert" pattern. However, there is a hidden fourth step that is just as critical: Cleanup. When your tests interact with the outside world—like databases, file systems, or network services—leaving those resources open can lead to "leaky" tests, memory issues, and flaky builds. JUnit 5 provides a robust lifecycle management system, and for handling global, one-time cleanup tasks, the @AfterAll annotation is the industry standard. In this guide, we will explore the nuances of @AfterAll, its technical requirements, and how to use it to keep your test suite pristine. What is @AfterAll? The @AfterAll annotation is used to signal that the annotated method should be executed exactly once, after all the test methods in the current class have completed their execution. Think of it as the "garbage collector" for your test class. While @BeforeAll is responsible for heavy-duty initialization (like starting a Docker container or initializing a massive singleton object), @AfterAll is responsible for safely shutting those resources down.

Ankur in JUnit

Mastering JUnit 5: A Guide to the @BeforeEach Annotation

In modern Java unit testing, consistency and reliability are the twin pillars of a successful CI/CD pipeline. When you're testing complex business logic, you often need to perform identical setup steps—like initializing objects, mocking external services, or preparing data—before every single test. Without a centralized way to handle this, your test suite quickly becomes a "Copy-Paste" nightmare, leading to high maintenance costs and "flaky" tests. This is where the JUnit 5 @BeforeEach annotation becomes an essential tool in your developer toolkit. What is @BeforeEach? The @BeforeEach annotation marks a method that must run before every individual @Test method in the current class. Its primary goal is to ensure test isolation. By resetting the state before every test, you guarantee that "Test A" cannot leave behind data that causes "Test B" to pass or fail incorrectly. The Evolution: From JUnit 4 to JUnit 5 If you are migrating legacy code, remember that @BeforeEach is the direct successor to JUnit 4’s @Before. While the name has changed to be more descriptive, the core concept remains the same: it’s your primary lifecycle hook for per-test initialization.

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.

Ankur in 8086

8086 Assembly Program to Compute the Power of a Number Using Exponentiation by Squaring

This blog post details an 8086-assembly program that computes the power of a number using the Exponentiation by Squaring algorithm (O(log n) efficiency). While a standard iterative approach multiplies the base n times (taking O(n) time), exponentiation by squaring—also known as binary exponentiation—works by breaking the exponent down into its binary components. By squaring the base in each step and only multiplying it into the result when a bit in the exponent is set, we drastically reduce the computational load. For example, calculating x32 requires only 5 multiplications instead of 31. This example demonstrates advanced assembly concepts like bitwise manipulation, conditional branching, and efficient arithmetic optimization. Let’s get started! Logic Breakdown: The algorithm follows the mathematical identity of Binary Exponentiation: Check Exponent: If it's zero, stop. Odd Case: If the current exponent is odd, multiply the running result by the current base. Square and Halve: Regardless of odd/even, square the base and divide the exponent by 2. Loop: Continue until the exponent is exhausted. Let's visualize it's working for 53. StepBase ExponentResult ActionInitial531Start loopIter 153 (Odd)51 X 5 = 5Square251552 = 25, 3/2 = 1Iter 2251 (Odd)1255 X 25 = 125Square6250125252 = 625,1/2 = 0Exit-0125Loop terminates

Ankur in JUnit

JUnit 5 @RepeatedTest: Improve Test Reliability with Repeated Test Execution

In the competitive landscape of Java development, flakiness is the ultimate enemy of progress. We have all experienced the "Heisenbug" frustration: you write a test, it passes flawlessly on your local machine, but it fails intermittently once it hits the CI/CD pipeline. These non-deterministic failures erode trust in the build process and waste hours of engineering time. To combat this instability, JUnit 5 introduced a robust solution: the @RepeatedTest annotation. Whether you are hunting down elusive race conditions, validating random data generators, or stress-testing intermittent network calls, repeating a test is a proven strategy for ensuring long-term stability. Today, we’ll dive deep into how to use @RepeatedTest to transform your test suite from "mostly reliable" to "battle-hardened." What is JUnit 5 @RepeatedTest? The @RepeatedTest annotation is a specialized programming model in JUnit Jupiter that allows you to execute a single test method a specific number of times. Unlike a standard @Test annotation, which executes a method exactly once, @RepeatedTest signals the JUnit Jupiter engine to treat the method as a template. The engine then generates multiple dynamic test invocations based on that template.

Ankur in 8086

8086 Assembly Program to Compute the Power of a Number

This blog post details an 8086-assembly program that computes the power of a number, specifically baseexponent. This example demonstrates fundamental assembly concepts like loops, multiplication, and register manipulation to perform iterative arithmetic. Let’s get started! data segment base dw 0003h exponent dw 0004h result dd ? data ends code segment assume cs:code, ds:data start: ; Initialize data segment mov ax, data mov ds, ax ; Initialize result to 1 (R = B^0) mov word ptr result, 0001h mov word ptr result+2, 0000h ; Load base and exponent mov cx, exponent ; CX = exponent (loop counter) mov bx, base ; BX = base cmp cx, 0000h je exit ; If exponent is 0, result is already 1. Jump to exit. power_loop: ; Multiply result by base ; The result is a 32-bit number in result[0] (lower word) and result[2] (upper word) ; Multiplication requires careful handling of the 32-bit result with a 16-bit multiplier. ; 1. Multiply the lower word of result by base mov ax, word ptr result ; AX = result[0] mul bx ; AX * BX -> DX:AX (32-bit product) push dx ; Save the higher word (DX) of the product mov word ptr result, ax ; Store the lower word (AX) of the product as the new result[0] ; 2. Multiply the upper word of result by base mov ax, word ptr result+2 ; AX = result[2] mul bx ; AX * BX -> DX:AX (32-bit product) ; 3. Add the two 16-bit 'carry' terms pop cx ; Retrieve the saved higher word (DX) from step 1 into CX add ax, cx ; AX = AX + CX (Sum of two high words) adc dx, 0000h ; DX = DX + 0 + Carry from the previous ADD (final carry from the 32-bit multiplication) ; 4. Store the final upper word mov word ptr result+2, ax ; Store AX as the new result[2] ; Handle the 32-bit overflow (DX is the final carry from the 32-bit multiplication) ; For a 32-bit result storage, this program assumes the result fits in 32-bits. ; If the power is large, overflow might occur, which is a limitation of this 32-bit storage approach. loop power_loop ; Decrement CX and jump back to power_loop if CX != 0 exit: int 3 ; Program termination code ends end start