Let's begin!

AI

Continuous Development with Claude Code on GitHub demonstrates how we can use the Claude GitHub App and Claude Code for implementing features and reviewing PRs.

AI Coding will Prevent Expertise warns that heavy reliance on AI creates an illusion of competence and argues that true expertise is built through failing and solving hard problems yourself.

The current AI pricing was always going to go away explains why subsidized flat-rate AI pricing will eventually be replaced by usage-based billing.

Better tools made Copilot code review worse. Here’s how we actually improved it explains why replacing the code exploration tools of the GitHub Copilot code review agent led to worse reviews and describes how GitHub fixed this problem.

Viability of local models for coding identifies the key factors that determine if running local LLMs for programming is worth it.

Experiences with local models for coding describes what happened when the author used local LLMs for completing real programming tasks.

Reviewing AI Code Is Not A Viable Argument challenges the belief that humans can effectively review AI-generated code and ensure that only "good code" is merged to main.

The AI hype is a mass psychosis echo chamber of incompetent individuals rants that one of the main reasons behind the AI hype is that AI gives incompetent individuals a false sense of competence.

The AI Productivity Illusion explains why generating more things in less time doesn't necessarily increase economic productivity.

The Economic Benefit of Refactoring documents an experiment where the author demonstrated that refactoring AI-generated (and messy) code reduces the future token consumption of AI agents.

Software Development

Waterfall Was Never the Problem argues that waterfall is actually a good choice in certain situations and points out that critics often attack Royce's initial version instead of the final product. Finally, the author explains how AI fixes waterfall's biggest problem.

Nulling Out References Won’t Help Your Garbage Collector busts the myth that setting local variables to null helps the JVM garbage collector do its job more efficiently.

When NOT TO USE Event-Driven Architecture (EDA) identifies seven situations where we shouldn't use event-driven architecture because it adds unnecessary complexity and causes issues in production.

OWASP Top 10 2025 identifies the new OWASP Top 10 for 2025, compares it to the 2021 list, and analyzes what has changed in web security over the past four years.

The cost of saying yes has changed argues that even though AI has dramatically reduced the cost of writing code, the cost of owning, reviewing, and maintaining code hasn't changed.

The Archaeologist’s Copilot explores how software developers can use AI for investigating and modernizing legacy codebases.

The Conductor Developer describes how we are shifting from solo coding to "orchestrating" AI agents and argues that because AI agents write more code, human attention has become the new bottleneck.

The post Software Development Monthly 7 / 2026 appeared first on Petri Kainulainen.

    

The post New RSS Feed appeared first on Petri Kainulainen.

    

Let's begin!

Test Design

Test The Feature: Now With Examples provides code examples which demonstrate why end-to-end tests should concentrate on testing features instead of single API endpoints.

Your AI Generated 400 Tests. They All Pass. None of Them Catch the Bug That Ships to Production. identifies the pros and cons of AI generated tests, explains why AI generated tests can create false confidence, and describes how we can solve this issue by using better prompts and doing mutation testing.

Your Test Automation May Be Revealing Team Problems explains how test automation issues such as fragile tests and knowledge silos can be caused by organizational problems like poor collaboration and weak onboarding.

Stop Mocking Everything: The 3 Tests I Start With for a Service argues that we should stop mocking everything and introduces a three-test strategy that helps us write (or generate) better tests that test the behavior, not the implementation.

Backend

Spring Cloud Contract Is Coming Home: Introducing Stubborn Contract announces that Spring Cloud Contract is transitioning out of the Spring Cloud portfolio. The original author of the project will continue to support it under the name Stubborn Contract. This blog post identifies the reasons behind the change and explains what current users can expect during the migration.

Testing OAuth2 client login with mock-oauth2-server is a practical guide that helps us to write tests for Spring Boot OAuth2 client authentication. It explains how we can start a lightweight OAuth2 server when our integration tests are run and write tests for authentication flows without relying on external providers or heavy Docker containers like Keycloak.

Testing Spring MVC HandlerInterceptor provides a quick introduction to the HandlerInterceptor interface, describes how we can implement and register a custom HandlerInterceptor, and explains how we can write automated tests for our implementation.

Introduction to Spring MockMvc is a complete introduction to Spring MockMvc. It highlights the benefits of Spring MockMvc, identifies its key components, and describes how we can get the required dependencies with Maven and Gradle.

UI / End-to-End

Scaling Playwright‑BDD to 3,000+ Tests Without Losing Your Mind identifies six patterns that help us to write large BDD test suites that are both fast and maintainable.

Highly Scalable Test Data Management in Playwright describes how we can manage the test data of our Playwright tests by using fixtures.

What to Check When Your Playwright Test Passes Locally But Fails in CI explains why Playwright tests can fail in CI environments with blank screenshots and provides a step-by-step process that helps us to debug these failing tests.

Why Simple UI Tests Become Slow identifies some of the problems which slow down our UI tests and provides tips that help us to optimize the performance of our UI tests.

Page Object Model Is Not Enough: The 4 Layers Real Frameworks Use explains why using only the page object model is insufficient for large test suites and describes how we can write maintainable tests by implementing a four-layer test automation framework.

Playwright in Pictures: How Fixtures Work is a comprehensive tutorial which uses timeline charts to explain how Playwright fixtures work.

The post Clean Test Automation Monthly 7 / 2026 appeared first on Petri Kainulainen.

   

Related Stories

• Clean Test Automation Monthly 7 / 2025
• Clean Test Automation Monthly 7 / 2023
• Clean Test Automation Monthly 7 / 2024

 

After we have finished this blog post, we:

• Understand what Spring MockMvc is.
• Can identify the key components of Spring MockMvc.
• Know how we can get the required dependencies with Maven and Gradle.

Let's begin.

What Is Spring MockMvc?

Spring MockMvc is a testing tool which provides support for testing Spring MVC controllers. The benefits of Spring MockMvc are:

• No Web Server Required. Because Spring MockMvc is built on top of the Servlet API mock objects provided by the spring-test module, it doesn't require a servlet container and the tests which use it bypass the network layer. Thus, our tests are as fast as possible.
• Full Spring MVC Runtime Support. Because Spring MockMvc uses the DispatcherServlet class that provides full support for the Spring MVC runtime behavior, we can test real request mappings, parameter binding, request validation, error handling, and JSON serialization/deserialization.
• Test Framework Agnostic. We can write our tests by using JUnit 4, JUnit 5, or TestNG. We can also use other testing frameworks as long as the testing framework provides support for Spring MockMvc or we use the standalone configuration.
• Flexible Test Configuration. We can configure the system under test by using a lightweight standalone configuration, a focused test slice (@WebMvcTest), or a web application context based configuration. We will talk more about these configuration options in the next posts of this tutorial.
• Flexible Assertion Support. We can write assertions by using Spring's MockMvcResultMatchers (together with Hamcrest or JSONPath), write assertions for the MvcResult object by using our favorite assertion library, or leverage the fluent MockMvcTester API and write our assertions with AssertJ.

Next, we will take a look at the key components of Spring MockMvc.

The Key Components of Spring MockMvc

Spring MockMvc provides two main styles for writing tests:

• The Classic MockMvc API which uses static factory methods.
• The Modern MockMvcTester API which was introduced in Spring Framework 6.2 / Spring Boot 3.4. The MockMvcTester API provides a fluent API for sending HTTP requests to the system under test and integrates Spring MockMvc with AssertJ.

Let's move on and take a look at the core components of both styles.

The Classic MockMvc API

If we use the traditional MockMvc API, our tests will interact with the following key classes:

• The MockMvc class acts as an entry point for our unit and integration tests. To be more specific, we will use this class when we send HTTP requests to the system under test.
• The MockMvcBuilders class provides static factory methods which allow us to create new MockMvc objects.
• The MockMvcRequestBuilders class provides static factory methods which we can use for creating the HTTP requests sent to the system under test.
• The MockMvcResultMatchers class provides static factory methods which allow us to write assertions for the returned HTTP response.
• The MockMvcResultHandlers class provides static factory methods which we can use when we want to print the returned HTTP response or write the HTTP response to a log file by using the Apache Commons Logging library.

The Modern MockMvcTester API

If we use the modern MockMvcTester API, our tests will interact with the following key classes:

• The MockMvcTester class is built on top of the MockMvc API. It provides a fluent API for building HTTP requests and sending them to the system under test.
• The MvcTestResult class contains the result of an executed HTTP request that was built with the MockMvcTester API. We can write assertions for the HTTP response by invoking the assertThat() method and passing the MvcTestResult object as a method parameter.
• The MvcTestResultAssert class implements the AssertJ assertions which we can use when we are writing assertions for the returned HTTP response.

Let's move on and find out how we can get the required dependencies with Maven and Gradle.

Getting the Required Dependencies

This section describes how we can get the required dependencies when we declare our dependencies one by one and when we use the dependency management of Spring Boot.

Declaring Our Dependencies One by One

If we are building a standalone Spring application without Spring Boot, we must declare the spring-test dependency in our build script.

If we are using Maven, we can declare this dependency by adding the following snippet to the dependencies section of our pom.xml file:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-test</artifactId>
    <version>7.0.8</version>
    <scope>test</scope>
</dependency>

If we are using Gradle, we have to add the spring-test dependency to the testImplementation dependency configuration.

If we are using the Groovy DSL, we have to add the following snippet to the dependencies block of our build.gradle file:

testImplementation('org.springframework:spring-test:7.0.8')

If we are using the Kotlin DSL, we have to add the following snippet to the dependencies block of our build.gradle.kts file:

testImplementation("org.springframework:spring-test:7.0.8")

Using the Dependency Management of Spring Boot

If we use Spring Boot, we only need to declare the spring-boot-starter-test dependency in our build script. The dependency management of Spring Boot will automatically get compatible versions of all essential testing libraries (including JUnit Jupiter, Mockito, AssertJ, and Spring Test).

If we are using Maven, we can declare this dependency by adding the following snippet to the dependencies section of our pom.xml file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
</dependency>

If we are using Gradle, we have to add the spring-boot-starter-test dependency to the testImplementation dependency configuration.

If we are using the Groovy DSL, we have to add the following snippet to the dependencies block of our build.gradle file:

testImplementation('org.springframework.boot:spring-boot-starter-test')

If we are using the Kotlin DSL, we have to add the following snippet to the dependencies block of our build.gradle.kts file:

testImplementation("org.springframework.boot:spring-boot-starter-test")

Let's summarize what we learned from this blog post.

Summary

This blog post has taught us five things:

• Spring MockMvc doesn't require a servlet container and the tests which use it bypass the network layer.
• Spring MockMvc provides full support for the Spring MVC runtime behavior because it uses the real DispatcherServlet class behind the scenes.
• The classic MockMvc uses static builders and matchers and the modern MockMvcTester provides a fluent API with AssertJ integration.
• If we are building a standalone Spring application without Spring Boot, we must declare the spring-test dependency in our build script.
• If we use Spring Boot, we only need to declare the spring-boot-starter-test dependency in our build script.

The post Introduction to Spring MockMvc appeared first on Petri Kainulainen.

   

Related Stories

• Writing Unit Test With MockMvcTester: Returning an Object as JSON
• Writing Unit Tests With MockMvcTester: Returning a List as JSON
• Introduction to MockMvcTester

 

Let's begin!

AI

Loop Engineering provides an introduction to loop engineering where developers design automated feedback loops that programmatically prompt and orchestrate AI agents.

AI-assisted engineers are burning out, is this fine? explains why AI assisted software development can cause burnout and provides five tips that help developers to maintain a sustainable workflow.

Vibe Coder vs Software Engineer explains the difference between a vibe coder and a software engineer.

OpenAI Losses Increased Nearly 8X in 2025 reveals that, according to audited financial documents, OpenAI lost $38.5 billion in 2025.

Did AI Just Break Software Security For Ever? argues that because AI assisted vulnerability research increases the number of vulnerabilities patched in active and well-maintained code bases, the software which uses end-of-life versions becomes exposed to rapid exploitation.

Tool Calling in Spring AI 2.0: A Composable, Agentic Architecture describes how Spring AI 2.0 improves the tool calling architecture by adding better support for customizing and extending the tool calling loop.

Self-Correcting Structured Output in Spring AI 2.0 introduces the improvements to Spring AI's structured output support that were released in Spring AI 2.0.

Why Your Codebase Is Forcing AI to Underperform, and What to Do About It explains why unused code is a problem and describes how we can safely remove it by using an AI agent to analyze and clean up our code base.

Software Development

Performance Improvements in JDK 26 highlights the notable performance improvements introduced in JDK 26.

Spring Boot Migration and the CRA: When Good Enough Isn’t explains how the upcoming EU Cyber Resilience Act introduces compliance liabilities for organizations running unsupported and vulnerable software.

Spring vs Quarkus vs Jooby vs Vert.x: Pick Your Next Java Framework compares four Java frameworks, and identifies the pros and cons of each framework.

Don't Pollute Your Spring Boot Main EntryPoint Class explains why it's not a good idea to include "unnecessary" configuration in the Spring Boot's entry point class.

Spring Boot 4.1 Adds gRPC Auto-Configuration, SSRF Mitigation, and Kotlin 2.3 Support highlights the major improvements introduced in Spring Boot 4.1.

MongoDB-backed Spring Batch jobs and more in Spring Boot 4.1 describes how we can write Spring Batch jobs which store the metadata in a MongoDB database.

The post Software Development Monthly 6 / 2026 appeared first on Petri Kainulainen.

    

Let's begin!

Test Design

API Tests – Rent You Don’t Need to Pay defines the term API test, identifies the cost of "duplicate test coverage", and shares practical tips that help us to write good API tests.

The AI Testing Hangover: When More Automation Means Less Confidence identifies the cost of valuing quantity over quality, argues that we shouldn't track code coverage, shares four metrics which are more useful, and explains what we should do next.

System/UI Tests – The Layer You Should Hate Needing defines the term system test, identifies bugs that only a system test can catch, and helps us to build a reliable and useful system test suite.

The Spec Is the Contract: How SDD Is Changing API Test Strategy describes how spec-driven development can help us to do contract testing, identifies three risks of spec-driven development, and explains how QA engineers can gain an advantage by co-owning the specification documents.

The Conversation You’re (Probably) Not Having describes how both QA engineers and developers can increase confidence and reduce production bugs by building healthy collaboration habits.

Test the Feature, Not the Endpoint argues that API tests which test only only one API endpoint don't help us to verify that a feature is working as expected. Thus, if we want to ensure that a feature is working as expected, we should write workflow tests.

Backend

Tiberius: A Security Testing Framework for LLM Applications in Java provides a quick introduction to Tiberius which is a vulnerability and security testing library that integrates with both JUnit Jupiter and Spring Boot.

Rest-Assured Configuration and Specifications: Writing Maintainable API Tests demonstrates how we can remove duplicate code from our API tests which use Rest Assured.

The Jqwik Anti-AI Affair explains why the author of the Jqwik library decided to add the "infamous line" to the standard output of each test run.

UI / End-to-End

Three Paths to Agentic UI Automation identifies three different approaches which an AI agent can use when it wants to drive a browser, explains the pros and cons of each approach, and helps us to select the correct approach.

Data Driven API Testing in Playwright TypeScript: Part 1 and Part 2 is a two part tutorial that provides a quick introduction to data-driven testing and explains how we can write data-driven API tests with Typescript and Playwright.

Mocking Server Side HTTP in Playwright with mockttp describes how we can write Playwright tests which mock HTTP requests with mockttp.

The post Clean Test Automation Monthly 6 / 2026 appeared first on Petri Kainulainen.

   

Related Stories

• Clean Test Automation Monthly 6 / 2025
• Clean Test Automation Monthly 6 / 2024
• Clean Test Automation Monthly 6 / 2023

 

Let's begin!

AI

Appearing Productive in The Workplace argues that generative AI enables employees to impersonate expertise and helps to create a false sense of productivity.

Bun's problem may be developing in the open explains how public and transparent development can backfire if users mistake experiments for code that will be actually released.

AI Is Too Expensive argues that the only companies which can make money from generative AI are construction companies, NVIDIA, and hardware manufacturers.

Is AI Profitable Yet? tracks the gap between costs and revenue of AI companies (in "real" time).

The Eternal Sloptember explains that adopting AI agents is a costly mistake, especially for large organizations, because the bottom performers generate ten times more code without understanding the generated code.

The solution might be cancelling my AI subscription argues that because AI tools have made it so easy to generate code, the author has wasted time generating multiple side projects he has no hope or interest in maintaining.

Test software tells code bots ‘delete me’ — AI bros outraged reports an incident where a jqwik maintainer added a log message which asked AI agents to delete all jqwik tests and code.

AI Writes Code. Engineers Build Software argues that even though AI is very good at generating code, it cannot do software engineering such as architecture design or requirements gathering.

Tokensparsamkeit for coding assistants explores methods for minimizing token consumption when we are using AI coding assistants.

Maintainability sensors for coding agents explores different tools we can use for guiding the AI agents to write more maintainable code.

With Claude: Less Coding, More Testing explains that using AI for generating code shifts the developer's primary role from writing code to verifying the output.

Software Development

Nobody Pushed Back: Why Engineers Stay Silent Until It's Too Late explains that if the company culture punishes people who speak up, people often choose safety over being right.

No Juniors Today, No Seniors in 2031 argues that if companies won't hire and mentor junior developers, they will face a critical shortage of senior engineers in 2031.

The pressure explains that the curl developers are facing a lot of pressure due to the massive influx of high-quality vulnerability reports and highlights a fundamental problem faced by even the most popular open source projects: lack of funding.

Learn SQL Once, Use It for 30 Years argues that because SQL is built on mathematical principles and not on shifting industry trends, we can learn it once and use it without the need to update our mental model.

Why JOIN USING Can Lead to Errors in SQL argues that even though JOIN USING is useful in ad-hoc queries, we shouldn't use it in production code because adding new columns to a database table can break existing queries which use the JOIN USING syntax.

Simplifying ANTI JOIN with jOOQ Syntax introduces different options for writing anti join queries with jOOQ.

What Is Code? argues that because AI makes code generation easier, we should concentrate on discovering the right vocabulary and building precise conceptual models.

Scaling ArchUnit with Nebula ArchRules describes how Netflix leverages ArchUnit for tracking quality issues across over 5000 repositories.

The post Software Development Monthly 5 / 2026 appeared first on Petri Kainulainen.

    

Let's begin!

Test Design

The Flaky Tests Truce argues that sometimes we should retry a failed test and provides five tips that help us to write tests that serve the product.

Why F.I.R.S.T. Testing Still Wins After 20 Years explains why we should write tests which are fast, isolated, repeatable, self-validating, and timely.

Most Test Frameworks Are Over-Engineered identifies the hidden costs of an elegant in-house testing framework and provides four questions that help us decide whether our own test framework is a solution or a problem.

The Pyramid Isn’t Dead, You’re Just Not Using It Right is the first part of the "The Test Pyramid — Reimagined" series, and it argues that a test pyramid is still a useful tool for making tradeoffs between the number of different (unit, integration, API, and system) tests, the duration of our test run, and maintenance costs. Remember to check out the next parts of the series: Unit Tests – Your Code’s Loudest Critic, Integration Tests – Reclaiming the Middle, and The Line You Forgot to Draw.

Backend

Parallel Testing With Gradle and JUnit 5 describes how we can run our tests in parallel with Gradle when we using JUnit Jupiter, and identifies two issues that can cause problems for parallel test runs and explains how we can solve them.

Getting Started With MockK: The Setup describes how we can get the required dependencies with Maven and Gradle, and configure the system under test by using both manual and extension-based configuration.

UI / End-to-End

Confessions of a Recovering Selenium Developer explains why the author stopped using Selenium and replaced it with Playwright.

Intercept Everything: API Logging Middleware for Playwright describes how we can implement a component that includes both the HTTP request and response in the HTML report generated by Playwright.

What Would You Stop Doing When UI Tests Are Flaky? explores this QA interview question and identifies the common (wrong) answers, explains why candidates are answering to the wrong question, and describes how the author would answer to this question.

Playwright Sharding and Docker: How I Cut My Test Suite from 47 Minutes to 8 Minutes explains why something had to be done and describes how the author cut 39 minutes from the run time of their Playwright regression test suite by using Playwright sharding, Docker, and Github Actions.

When Offline Isn't Enough: Adding Network Throttling to Playwright explains how we can simulate network constraints such as high latency and restricted upload or download speeds with Playwright.

The post Clean Test Automation Monthly 5 / 2026 appeared first on Petri Kainulainen.

   

Related Stories

• Clean Test Automation Monthly 5 / 2025
• Clean Test Automation Monthly 5 / 2024

 

After we have finished this blog post, we:

• Can get the required dependencies with Maven and Gradle.
• Understand how we can create mocks with MockK.

Let's begin.

Getting the Required Dependencies

Before we can write tests which use MockK, we have to choose between the standard MockK API and its BDD (Behavior-Driven Development) variant. Basically, we have to choose between the classic every/verify syntax and the BDD style given/then syntax. This choice defines the MockK module which we must add to the classpath.

The following table identifies the different modules provided by MockK:

Example 1: Gradle

If we want to use the standard MockK API with Gradle, we have to add the mockk dependency (version 1.14.9) to the testImplementation dependency configuration. We can do this by adding the following line to the dependencies block of our build.gradle.kts file:

testImplementation("io.mockk:mockk:1.14.9")

Example 2: Maven

If we want to use the standard MockK API with Maven, we have to add the mockk-jvm dependency (version 1.14.9) to the test scope. We can do this by adding the following dependency declaration to the dependencies section of our pom.xml file:

<dependency>
    <groupId>io.mockk</groupId>
    <artifactId>mockk-jvm</artifactId>
    <version>1.14.9</version>
    <scope>test</scope>
</dependency>

Next, we will take a closer look at the system under test.

Introduction to the System Under Test

During this blog post we will start writing tests for a component which allows us to register new user accounts. The implementation of this component is described in the following:

The User.kt file contains two data classes and one exception. These classes are:

• The RegisterUserAccountRequest class contains the information that's used to register a new user account.
• The UserAccount class contains the information of a user account that's found from the database.
• The UserAccountExistsException is a runtime exception that's thrown if the registered user account doesn't have a unique email address.

The source code of the User.kt file looks as follows:

data class RegisterUserAccountRequest(val email: String, val name: String)
data class UserAccount(val id: Long, val email: String, val name: String)
class UserAccountExistsException(email: String) :
    RuntimeException("The user account with email address: $email exists")

The UserRepository interface declares two functions:

• The existsByEmail() function returns true if the email address given as an argument is used by an existing user account and false otherwise.
• The save() function saves the user account provided as an argument and returns the information that's inserted into the database.

The source code of the UserRepository interface looks as follows:

interface UserRepository {
    fun existsByEmail(email: String): Boolean
    fun save(input: RegisterUserAccountRequest): UserAccount
}

The EmailService interface declares one function that's used to send a welcome email to a new user after their user account has been registered. The source code of the EmailService interface looks as follows:

interface EmailService {
    fun sendWelcomeEmail(email: String)
}

The UserAccountRegistrationService class has one function called registerUserAccount() that's implemented by following these steps:

1. Throw the UserAccountExistsException if the registered user account doesn't have a unique email address.
2. Insert a new user account into the database.
3. Send the welcome email to the user.
4. Return the information that was inserted into the database.

The source code of the UserAccountRegistrationService class looks as follows:

class UserAccountRegistrationService(
    private val repository: UserRepository,
    private val emailService: EmailService
) {
    fun registerUserAccount(input: RegisterUserAccountRequest): UserAccount {
        if (repository.existsByEmail(input.email)) {
            throw UserAccountExistsException(input.email)
        }
        val registeredUserAccount = repository.save(input)
        emailService.sendWelcomeEmail(registeredUserAccount.email)
        return registeredUserAccount
    }
}

Let's move on and find out how we can create mocks with MockK and configure the system under test with JUnit Jupiter.

Creating Mocks With MockK

When we are writing our tests with JUnit Jupiter and we want to create mocks with MockK, we have two viable options:

• We can create a mock manually by invoking the mockk() function.
• We can use the MockKExtension together with the @MockK and @InjectMockKs annotations.

Let's start and find out how we can create mocks manually by using the @BeforeEach function.

Creating Mocks Manually by Using the @BeforeEach Function

When we want to replace the UserRepository and the EmailService dependencies of the UserAccountRegistrationService class with mocks by using the @BeforeEach function, we have to follow these steps:

1. Create a new test class and add three private lateinit properties to the created test class:

• The repository property contains the UserRepository mock.
• The emailService property contains the EmailService mock.
• The service property contains the system under test (a UserAccountRegistrationService object).

After we have added these properties to our test class, its source code looks as follows:

class UserAccountRegistrationServiceManualTest {
    private lateinit var repository: UserRepository
    private lateinit var emailService: EmailService
    private lateinit var service: UserAccountRegistrationService
}

2. Add a setup function to our test class and ensure that this function is invoked before a test function is run. After we have added a new setup function to our test class, its source code looks as follows:

import org.junit.jupiter.api.BeforeEach
class UserAccountRegistrationServiceManualTest {
    private lateinit var repository: UserRepository
    private lateinit var emailService: EmailService
    private lateinit var service: UserAccountRegistrationService
    @BeforeEach
    fun configureSystemUnderTest() {
    }
}

3. Implement the setup function by following these steps:

1. Create new UserRepository and EmailService mocks by invoking the mockk() function and store the created mocks in the repository and emailService properties.
2. Create a new UserAccountRegistrationService object and store the created object in the service property.

After we have implemented the setup function, the source code of our test class looks as follows:

import io.mockk.mockk
import org.junit.jupiter.api.BeforeEach
class UserAccountRegistrationServiceManualTest {
    private lateinit var repository: UserRepository
    private lateinit var emailService: EmailService
    private lateinit var service: UserAccountRegistrationService
    @BeforeEach
    fun configureSystemUnderTest() {
        repository = mockk()
        emailService = mockk()
        service = UserAccountRegistrationService(repository, emailService)
    }
}

We have now configured the system under test by using the @BeforeEach function. Let's take a look at the pros and cons of this approach:

Pros:

• Tests are isolated. Because every test function gets new mocks and a new system under test, there is no risk of "configuration leakage". In other words, stubbed functions and verifications cannot leak from one test to another.
• Doesn't require a specific test instance lifecycle mode. If we create the required mocks and the system under test in the @BeforeEach function, our test functions are isolated in every supported test instance lifecycle mode of JUnit Jupiter. For example, because we create new objects and assign property values before every test function, our configuration guarantees a clean slate even if JUnit Jupiter is reusing the test class instance.
• Explicit dependency injection. Because we create the system under test manually in the @BeforeEach function, we don't have to worry about the reflection magic that's used if we configure the system under test by using annotations.
• Can be used as a design tool. Because we have to manually create the system under test, we will feel the pain immediately if the system under test has too many dependencies. If it feels cumbersome to write the code that configures the system under test or the constructor call becomes so long that it's hard to read, we should refactor the system under test.

Cons:

• Requires nullable or lateinit properties. Because the properties are initialized in a @BeforeEach function and not in a test class constructor, we are forced to use nullable types or lateinit properties. This is a problem because:
  • If we use a lateinit property: we must use var instead of val and we cannot rely on compile-time null safety. In other words, the property can be accidentally reassigned outside of the @BeforeEach function, or we might simply forget to assign its value. The problem is that instead of a compiler error, we get a runtime error during test execution.
  • If we use a nullable type: we have to pay the "null-safety" tax (either use the "bang-bang" operator (!!) or do safe calls (?.)), we have to provide a default value (null) that's immediately replaced either with a mock or the tested object, and we mask the intent of the property because in Kotlin a nullable type typically means that the value can be missing which isn't the case here.
• Requires boilerplate code. We have to write the setup code manually for every test class. This means that our test suite will have setup code that isn't, strictly speaking, required.
• Requires maintenance. If we add a new dependency to the system under test, we have to add a new lateinit property to our test class, create a new mock object in the @BeforeEach function, and modify the constructor call which creates the tested object.

Next, we will find how we can create mocks manually as immutable class properties.

Creating Mocks Manually as Immutable Class Properties

When we want to replace the UserRepository and the EmailService dependencies of the UserAccountRegistrationService class with mocks, and add these mocks and the system under test to our test class as immutable class properties, we have to create a new test class and follow these steps:

1. Add a private and immutable repository property to our test class and ensure that it contains a UserRepository mock.
2. Add a private and immutable emailService property to our test class and ensure that it contains an EmailService mock.
3. Add a private and immutable service property to our test class and ensure that it contains a new UserAccountRegistrationService object. Remember to pass the UserRepository and the EmailService mocks as constructor arguments.

After we have added the immutable class properties to our test class, its source code looks as follows:

import io.mockk.mockk
class UserAccountRegistrationServiceManualClassPropertyTest {
    private val repository = mockk<UserRepository>()
    private val emailService = mockk<EmailService>()
    private val service = UserAccountRegistrationService(repository, emailService)
}

We have now configured the system under test by using immutable class properties. Let's take a look at the pros and cons of this approach.

Pros:

• All class properties are immutable. They cannot be reassigned and they cannot be null.
• Tests are isolated (if we use the correct test instance lifecycle mode). Because every test function gets new mocks and a new system under test, there is no risk of "configuration leakage". In other words, stubbed functions and verifications cannot leak from one test to another.
• Explicit dependency injection. Because we create the system under test manually, we don't have to worry about the reflection magic that's used if we configure the system under test by using annotations.
• Can be used as a design tool. Because we have to manually create the system under test, we will feel the pain immediately if the system under test has too many dependencies. If it feels cumbersome to write the code configures the system under test or the constructor call becomes so long that it's hard to read, we should refactor the system under test.

Cons:

• JUnit Jupiter must create a new test instance for every test function (this is the default behavior). As long as JUnit Jupiter creates a new test instance for every test function, there is no risk of "configuration leakage". If the JUnit Jupiter is configured the create a new test instance once per test class, a test function will inherit the stubs and recorded interactions from the previous test function (if we don't do manual cleanup). This shared state can lead to flaky tests where the outcome of one test depends on the execution order of the other tests.
• Requires boilerplate code. We have to write the setup code manually for every test class. This means that our test suite will have setup code that isn't, strictly speaking, required.
• Requires maintenance. If we add a new dependency to the system under test, we have to add a new immutable class property to our test class, create a new mock object, and modify the constructor call which creates the tested object.

Let's move on and find out how we can create mocks by using the JUnit Jupiter extension together with the @MockK and @InjectMockKs annotations.

Using the JUnit Jupiter Extension

When we want to replace the UserRepository and the EmailService dependencies of the UserAccountRegistrationService class with mocks by using MockK JUnit Jupiter extension, we have to follow these steps:

1. Create a new test class and add three private lateinit properties to the created test class:

• The repository property contains the UserRepository mock.
• The emailService property contains the EmailService mock.
• The service property contains the system under test (a UserAccountRegistrationService object).

After we have added these properties to our test class, its source code looks as follows:

class UserAccountRegistrationServiceExtensionTest {
    private lateinit var repository: UserRepository
    private lateinit var emailService: EmailService
    private lateinit var service: UserAccountRegistrationService
}

2. Annotate the repository and emailService properties with the @MockK annotation. This annotation identifies the properties that contain mocks and instructs the MockK JUnit Jupiter extension to create the required mock objects. After we have annotated these properties with the @MockK annotation, the source code of our test class looks as follows:

import io.mockk.impl.annotations.MockK
class UserAccountRegistrationServiceExtensionTest {
    @MockK
    private lateinit var repository: UserRepository
    @MockK
    private lateinit var emailService: EmailService
    private lateinit var service: UserAccountRegistrationService
}

3. Annotate the service property with the @InjectMockKs annotation. This annotation identifies the property initialized by the MockK JUnit Jupiter extension and instructs it to replace the dependencies of the created object with mocks. After we have done this, the source code of our test class looks as follows:

import io.mockk.impl.annotations.InjectMockKs
import io.mockk.impl.annotations.MockK
class UserAccountRegistrationServiceExtensionTest {
    @MockK
    private lateinit var repository: UserRepository
    @MockK
    private lateinit var emailService: EmailService
    @InjectMockKs
    private lateinit var service: UserAccountRegistrationService
}

4. Register the used JUnit Jupiter extension by annotating our test class with the @ExtendWith annotation. After we have registered the MockKExtension, the source code of our test class looks as follows:

import io.mockk.impl.annotations.InjectMockKs
import io.mockk.impl.annotations.MockK
import io.mockk.junit5.MockKExtension
import org.junit.jupiter.api.extension.ExtendWith
@ExtendWith(MockKExtension::class)
class UserAccountRegistrationServiceExtensionTest {
    @MockK
    private lateinit var repository: UserRepository
    @MockK
    private lateinit var emailService: EmailService
    @InjectMockKs
    private lateinit var service: UserAccountRegistrationService
}

We have now configured the system under test by using the MockK JUnit Jupiter extension. Let's take a look at the pros and cons of this approach:

Pros:

• Tests are isolated. The MockK JUnit Jupiter extension ensures that every test function gets clean mocks. In other words, it makes sure that stubbed functions and verifications cannot leak from one test to another.
• Minimal Boilerplate. We don't have to manually invoke the mockk() function or invoke the constructor of the tested class. We can simply describe what we want by using the @MockK and @InjectMockKs annotations, and the MockK JUnit Jupiter extension will do the hard lifting for us.
• Clean Class Structure. Because the MockK JUnit Jupiter extension creates the mock objects and the tested object, our test class looks clean. All properties are listed at the top of the test class, and the @MockK and @InjectMockKs annotations make it clear what's mocked and what's tested.

Cons:

• Requires nullable or lateinit properties. Because the test class properties are initialized by the MockK JUnit Jupiter extension after the test class is instantiated (and not in a test class constructor), we are forced to use nullable types or lateinit properties. This is a problem because:
  • If we use a lateinit property: we must use var instead of val and we cannot rely on compile-time null safety. In other words, the property can be accidentally reassigned, or we might simply forget to assign its value. The problem is that instead of a compiler error, we get a runtime error during test execution.
  • If we use a nullable type: we have to pay the "null-safety" tax (either use the "bang-bang" operator (!!) or do safe calls (?.)), we have to provide a default value (null) that's immediately replaced either with a mock or the tested object, and we mask the intent of the property because in Kotlin a nullable type typically means that the value can be missing which isn't the case here.
• Hides bad design. Because it's so easy to create a new mock and inject it into the system under test, we might not realize that the system under test has too many dependencies until it's too late. In other words, we don't feel the "constructor friction" that acts as a design tool.
• Relies on reflection and "magic". The MockK JUnit Jupiter extension relies heavily on reflection. This leads into a "magic" behavior that's harder to debug than plain Kotlin code. Also, if something goes wrong, it's likely that we will get a confusing error message at runtime instead of a clean compilation error.

We can now get the required dependencies with Maven and Gradle, and we understand how we can create mocks with MockK. Let's summarize what we learned from this blog post.

Summary

This blog post has taught us four things:

• If we want to use the standard MockK API with Gradle, we have to add the mockk dependency to the testImplementation dependency configuration. We don't have to specify the variant we want to use because Gradle can read its own .module metadata and resolve the correct variant automatically.
• If we want to use the standard MockK API with Maven, we have to add the mockk-jvm dependency to the test scope. We must explicitly specify the variant we want to use because Maven cannot read Gradle's .module metadata.
• We must choose whether we want to couple our tests to a specific test instance lifecycle mode or ensure that our tests are working as expected regardless of the lifecycle configuration. This decision dictates how we can configure the system under test.
• We must make a trade-off between automation and design feedback. The MockKExtension and annotations reduce boilerplate code, but the manual configuration acts as an architectural design tool which alerts us when a class has too many dependencies.

P.S. You can get the example application from Github.

The post Getting Started With MockK: The Setup appeared first on Petri Kainulainen.

    

Let's begin!

AI

Vulnerability Research Is Cooked argues that a substantial amount of vulnerability research will be replaced with AI agents which will scan code bases for zero day vulnerabilities.

Claude Is Not Your Architect. Stop Letting It Pretend. explains why we shouldn't let Claude (or any other AI agent) to sit on the driver's seat.

AI Use Appears to Have a "Boiling Frog" Effect on Human Cognition summarizes the results of a research which claims that AI improves short term performance, but this improvement comes at a heavy cognitive cost.

AI-Assisted Java Application Development with Agent Skills describes how we can optimize the context size by leveraging agent skills.

Spring AI Agentic Patterns (Part 6): AutoMemoryTools — Persistent Agent Memory Across Sessions explains how we can give our AI agents a long-term memory that can be accessed by different sessions.

Spring AI Agentic Patterns (Part 7): Session API — Event-Sourced Short-Term Memory with Context Compaction provides an introduction to Spring AI Session which adds support for storing the conversation history to a short-term memory.

The Software Factory: Why Your Team Will Never Work the Same Again explains how the rise of software factories is changing the way we write code.

The AI Great Leap Forward argues that the current AI boom is a 'Great Leap Forward' that destroys software quality by prioritizing quantity and speed over human expertise.

Total Skill Collapse Is How AI Makes Idiocracy a Reality argues that AI model collapse is accelerated by the fact that no one has incentive to publish original content on the internet.

Agentic Coding is a Trap explains that agentic coding is a trap because over time developers lose both the ability to write code and the deep system understanding required to maintain complex software.

GitHub Copilot is moving to usage-based billing announces that GitHub Copilot moves from flat-rate subscriptions to usage-based billing.

Cloud

S3 Files and the changing face of S3 introduces a new AWS feature called S3 files which allows us to use S3 as a network attached file system.

Software Development

"What’s In It For Me" Architecture argues that a good architect has excellent soft skills and provides three tips that help architects to convince other people to implement their designs.

A Year Long Rewrite describes the challenges the author faced when they decided to rewrite the code of their text editor.

Things you didn't know about indexes provides an introduction to database indexes and identifies some pitfalls which make our queries slower than they could be.

No one owes you supply-chain security argues that open-source developers aren't responsible for the supply-chain security of the companies who profit from the open-source software.

The Danger of "Modern" Open Source examines the risks of the modern open-source ecosystem where companies exploit open-source maintainers for free.

Java Is Fast. Your Code Might Not Be. argues that the performance issues of Java applications are caused by inefficient coding patterns.

One Method Was Using 71% of CPU. Here's the Flame Graph. explains how we can investigate the performance of a Java application and demonstrates how the implementation of one method can lead to a massive bottleneck.

When You Can Safely Leave Sprints Behind argues that the traditional time-boxed sprints are useful when we are trying to build good habits, but we can move forward to continuous flow models once our workflow is stable and predictable.

Spring Boot Configuration Properties at Scale describes how we can manage complex Spring Boot configurations which are used by huge applications.

The Spring Team on Spring Framework 7 and Spring Boot 4 highlights the architectural and functional improvements introduced in Spring Framework 7 and Spring Boot 4.

Ghostty Is Leaving GitHub explains that Ghostly is leaving GitHub because of GitHub outages.

Before You Judge, Get Curious describes why we should ask questions instead of judging people who disagree with us.

The post Software Development Monthly 4 / 2026 appeared first on Petri Kainulainen.