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.

    

Let's begin!

Test Design

My thoughts on 'self-healing' in test automation defines the term self-healing test automation and explains why it's a bad idea.

Rethinking Your Test Strategy for AI-Powered Features is a comprehensive article which explains what we have to take into account when we are testing AI-powered features.

You’re Not Meta: Build Fast Teams with Fast Tests argues that for most companies writing high-speed test suites is critical for ensuring that we can move forward as fast as possible.

Letting AI play my game explains how the author used AI for testing his game where a crossword builds the map of an old-school dungeon crawler.

You Climbed the Test Pyramid. Now Eat a Custard Slice introduces a new mental model that ignores technical scope and categorizes tests by the value they provide.

Eliminating Flaky Tests to End World Hunger explains why flaky tests are bad, identifies five reasons why our tests are flaky, and highlights seven strategies that help us to get rid of flaky tests.

The Flaky Test Files: The Case of the State Pollution descibes how state pollution causes flaky tests.

BDD Gherkin Guidelines for AI Coding and Testing announces the release of Gherkin Guidelines for AI. It's an open source context file that helps AI agents to write better Gherkin scenarios.

How and Why to Trace Use Cases and Tests explains why we must be able to link tests with use cases, describes how we can do it with a custom annotation, and announces the release of the AI Unified Process Navigator for IntelliJ plugin which makes the tracking process easier and faster (if we use IntelliJ Idea).

How to Handle Failing Tests Caused by a Known Bug argues that if a test case fails because of a bug that cannot be fixed immediately, we should configure our test framework to skip the failed test case.

Backend

Testing Elasticsearch. It just got simpler. describes how Elasticsearch 9.x and Testcontainers 2.x have made it easier to write tests for code which uses Elasticsearch.

UI / End-to-End

Signals Are Not Guarantees argues that many end-to-end tests contain assertions which are written on the wrong level, and explains how we can fix this problem.

Evolving POM: From Page Objects to Agent-Friendly Design describes how we can move from the classic page objects to page objects which can be leveraged by AI agents.

Migrating from Selenium to Playwright: The Complete Guide explains how we can evaluate the costs and risks of the migration, identifies four situations when the migration makes no sense, and describes how we can get the job done if we decide to do it.

Playwright Accessibility Testing: What axe and Lighthouse Miss identifies the accessibility issues which are missed by automated accessibility tools, describes how we can write better accessibility tests, and explains what must be tested manually.

My 2 Cents: I'll gladly spend them to stop staring at test logs describes how Trivago built an AI tool which analyzes test failures and publishes its analysis on Github Actions workflow summary.

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

   

Related Stories

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

 

Let's begin!

AI

Why I stopped using AI code editors warns that overusing AI code editors can lead to a loss of technical intuition and fundamental engineering skills.

Writing code was never the bottleneck argues that writing code faster is a reasonable goal, but it doesn't eliminate the real bottlenecks. The author identifies some of these bottlenecks and describes how we can remove them with Claude Code and Github Actions.

AI Use at Work Is Causing "Brain Fry", Researchers Find, Especially Among High Performers explains that constant interaction with AI tools can lead to cognitive overload, fatigue, and slower decision-making.

How I Dropped Our Production Database and Now Pay 10% More for AWS is a post mortem of an incident where a Claude Code agent wiped the production AWS infrastructure (including the database) and deleted all automated backups.

The Software Development Lifecycle Is Dead argues that AI agents have collapsed the traditional software development lifecycle into a tight loop of intent, execution, and observation.

Every layer of review makes you 10x slower explains how every layer of approval drastically decreases our velocity, and argues that even though AI can generate code faster, the only way to sustainably increase velocity is to do fewer reviews.

AI Agent Hacks McKinsey: 5 Situations When You Should Not Deploy Agents identifies five situations where we shouldn't use AI agents.

AI won't make you rich. But fixing bugs in AI slopware will argues that debugging and stabilizing AI generated code will be the next big economic opportunity for developers.

If you thought the speed of writing code was your problem - you have bigger problems argues that if we increase the amount of generated code with AI without addressing the real bottlenecks, we will only create "traffic jams" which reduce the amount of delivered value.

AI Coding is Gambling describes how coding has changed from an act that requires thinking to a form of gambling where developers pull a slot machine for solutions, and argues that this process makes the development work less satisfactory.

AI Made Writing Code Easier. It Made Being an Engineer Harder. argues that AI tools have made code generation faster, but the software engineering role has become more taxing, and the AI tools have caused an identity crisis for developers who love writing code.

Anatomy of the .claude/ Folder provides a comprehensive tutorial to the contents of the .claude/ directory. For example, the author provides an introduction to commands, rules, skills, and agents.

Thoughts on slowing the fuck down warns that agentic code generation can create unrecoverable technical debt, and argues that we should slow down and put the developer back to the driver's seat.

AI Tools for Developers Are Not Enough explains that even though teams can generate code faster than ever before, this doesn't guarantee that they will solve the right problems. The author argues that if we want to build the right thing faster, we need AI tools which support the whole software development lifecycle.

Writing an agent skill explains how we can optimize Claude Code's token usage by writing agent skills.

Claude Code Template for Spring Boot introduces the author's Claude Code template for Spring Boot applications. This template leverages both agents and skills, and its goal is to help us to generate production ready Spring Boot applications.

Cloud

Bucketsquatting is (Finally) Dead defines the term 'bucketsquatting' and explains how AWS solved this issue by introducing account specific S3 namespaces.

Software Development

Nobody Gets Promoted for Simplicity argues that engineering culture often values over-engineering and ignores the value of simple solutions.

Things I miss about Spring Boot after switching to Go identifies six Spring Boot features the author misses and highlights three things Go does better.

XML is a Cheap DSL argues that XML is an effective tool for building domain-specific languages.

Start naming your useEffect functions, you will thank me later argues that naming useEffect functions makes our code cleaner and helps us to identify effects that shouldn't exist.

The junior developer pipeline is broken, and nobody has a plan to fix it explores the problems caused by the collapsing junior developer hiring pipeline and identifies solutions that could help us solve them.

GitHub Actions Is Slowly Killing Your Engineering Team compares GitHub Actions and Buildkite, and argues that we should use Buildkite instead of GitHub Actions.

JavaScript (No, Not That One): Modern Automation with Java highlights modern Java features that have transformed Java into a viable scripting language.

Don’t trust, verify explains why we should verify that the tools we use were released by the correct "source" and haven't been tampered with.

axios Compromised: npm Supply Chain Attack via Dependency Injection is a comprehensive analysis of the supply chain attack where the popular axios NPM package was used to deliver malware.

Post Mortem: axios npm supply chain compromise is the official post mortem of the axios supply chain attack.

Announcing grüt - A Terminal File Explorer with Git, GitHub, and AI Integration introduces a new terminal-based file explorer that works in Linux, MacOS, and Windows.

Java 26 Is Here, And With It a Solid Foundation for the Future summarizes the key changes and new features introduced in Java 26.

Feeling Left Behind in Tech? This Is Your 90-Day Comeback Plan introduces a structured 90-day strategy that helps experienced developers to modernize their skill sets.

Speed up Java Startup with Spring Boot and Project Leyden explains how we can achieve up to a 75% faster startup time for Spring Boot applications.

Managing Sensitive Data in jOOQ 3.21+ Logs describes how we can exclude sensitive data from jOOQ logs.

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

    

Let's begin!

Test Design

AI and Testing: Using Local Models for Testing demonstrates how we can use local AI models for generating test cases and Playwright tests.

Your API Tests Are Passing. That’s the Problem argues that a green API test suite can create a false sense security, especially, if our test suite contains so called shallow assertions.

Generating code faster is only valuable if you can validate every change introduces a testing strategy that helps us to ensure that rapid code generation won't introduce bugs.

The Testing Pyramid is a Relic. Here is What Actually Works. argues that the testing pyramid doesn't work when we are writing modern distributed systems, and introduces a testing strategy which concentrates on static analysis, integration tests, and observability.

Who Tests the Tests? AI, QA, and the Verification Paradox explains what "don't trust without verification" means if we generate automated tests with AI.

Backend

Writing tests with Claude Code - part 1 - initial results describes what the author learned when he used Claude Code for generating automated tests for a Spring Boot REST API.

UI / End-to-End

Why We Chose Playwright Over Cypress compares Playwright and Cypress, and explains why the author decided to use Playwright.

17 Playwright Testing Mistakes You Should Avoid helps us to write better Playwright tests by identifying 17 mistakes we shouldn't make.

Test IDs are an a11y smell explains why the author thinks that we shouldn't use data-testid and describes how we can write tests which don't require test ids.

Making Code Coverage Work with Playwright explains how we can generate code coverage reports for Playwright tests with @bgotink/playwright-coverage.

Your Tests Are Green. Your App Is Broken identifies a situation where our application is broken even though our tests pass, and provides one possible solution to this problem.

Introducing Angular Testing Library Zoneless introduces the new @testing-library/angular/zoneless subpackage which is basically q trimmed down version of the original Angular Testing Library.

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

   

Related Stories

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

 

Let's begin!

AI

AI Doesn’t Reduce Work — It Intensifies It argues that AI causes workload creep where employees will increase their workload until they start to suffer from cognitive fatigue and burnout.

Context Is Now a First-Class Architectural Concern explains that context is no longer just data. It's a critical concern that must be designed and limited so that we can ensure that using AI is economically viable.

Inside OpenAI’s in-house data agent describes how OpenAPI build an in-house data agent that allows their employees to query over 600 petabytes of internal data and reduces the time it takes to get answers to their questions.

Lines of Code Are Back (And It's Worse Than Before) argues that AI-assisted coding has revived the lines of code (LOC) as a primary metric of productivity and explains why LOC is still an awful way to measure productivity.

An AI Agent Published a Hit Piece on Me (Part 1, Part 2, Part 3, and Part 4) provides a detailed account of an incident where an AI agent published a hit piece against an open source developer who closed a pull request opened by the AI agent.

Who opened the door? covers an incident where an AI agent started a smear campaign against a developer and identifies a question that's not asked by anyone else.

AI fatigue is real and nobody talks about it argues that even though AI helps us to finish individual tasks faster, it increases the time (and mental energy) needed to coordinate AI agents and review the finished work.

Minions: Stripe’s one-shot, end-to-end coding agents Part 1 and Part 2 introduces homegrown and unattended AI agents which produce over a thousand merged pull request every week.

What AI coding costs you identifies the negative effects of overrelying on AI tools, and argues that we should find a balance between AI assisted coding and old fashioned manual coding.

A Message To Devs At The Frontier argues that developers should be curious and embrace the new opportunities instead of simply ignoring AI assisted engineering.

Two Flavors of Spec-Driven Development and Why I Clearly Prefer One introduces two interpretations of spec-driven development and explains why the author thinks that one of them is essential for building business-critical systems.

You don’t have to if you don’t want to is a long and an old-fashioned rant about generative AI.

Software Development

Java has evolved. Your code can too highlights 113 code snippets and allows us to compare the old and modern implementation side by side.

Farewell, Rust explains why the author started using Node.js instead of Rust when he is doing web development.

Turn Dependabot Off argues that we shouldn't use Dependabot and explains what we should do instead.

Code Isn’t Slowing Your Project Down, Communication Is explains that delays in large organizations are rarely caused by the complexity of the produced code and argues that these delays are caused by poor communication, unclear processes, and clashing priorities.

Building Modular Monoliths With Kotlin and Spring explains why we should consider building modular monoliths and describes how we can build them with Kotlin and Spring Modulith.

Migrating to Modular Monolith using Spring Modulith and IntelliJ IDEA describes how we can migrate from a traditional monolith to a modular monolith.

Sinks, Not Pipes: Software Architecture in the Age of AI introduces techniques that help us to deal with AI agents that lack the long-term memory humans use to navigate poorly structured code bases.

How I estimate work as a staff software engineer explains why estimating is hard, argues that an estimate is a political tool, and describes how the author estimates work.

Deadlines As An Act Of Love argues that a deadline isn't an attempt to control employees. Instead, deadlines help us to schedule our work and support (or not to support) each other's objectives.

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

    

Let's begin!

Test Design

How to Keep Your Smoke Testing Useful argues that we should keep our smoke test suite as small (and fast) as possible and concentrate on testing things that matter.

The Big TDD Misunderstanding argues that we should write our tests from the user's perspective and provides four tips that help us to write good tests.

A Field Guide to Not Overengineering Test Automation describes how we can avoid writing an over-engineered test framework that requires more maintenance than our application.

When you outsource testing to the AI, you lose the ability to understand your system explains that if we outsource testing to AI, we will loose our mental model of the application because we don't get the understanding that's traditionally gained by writing tests and reading code.

Why AI won't save your Flaky Tests argues that if we use AI for fixing flaky tests, we will only hide the architectural issues which cause our tests to fail randomly.

Lessons I Wish I Knew When I Started in Test Automation identifies five lessons the author would have wanted to learn sooner.

Refactoring the RestAssured.Net code with Claude Code describes how the author used Claude Code to refactor the codebase of the RestAssured.Net project and explains what the author learned from this experiment.

Backend

Why We Should Not Mock Collections With Mockito explains why we should use real collections instead of mock objects when we are writing tests for code that uses collections (this a good advice for model objects as well).

Data Driven API Testing in Java with Rest-Assured and TestNG: Part 1, Part 2, Part 3, Part 4, and Part 5 describes how we can write data-driven tests with Rest Assured and TestNG (use the friend link if you don't have a Medium account).

UI / End-to-End

How I solved SMTP Timeouts with Mailpit and JavaMail explains how the author solved a DNS resolution issue which caused test failures when the system under test tried to send an email to localhost.

Testing Error Boundaries by Breaking Contracts, Not Code argues that we should test our frontend applications by intercepting successful API responses and injecting "contract violations" (such as missing fields or unexpected data types). This helps us to ensure that our UI degrades gracefully instead of crashing.

Using agent skills to write Playwright tests describes how the author generates end-to-end tests by leveraging AI agents.

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

   

Related Stories

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

 

Let's begin!

AI

We’re not concerned enough about the future of junior-level software engineering explains that because AI has basically removed the need for junior developers, companies will be in serious trouble when the current senior developers and architects retire because there won't be people who can replace them.

The John Henry Problem - Why Racing Against AI is a Losing Game argues that developers who compete with an AI are winning a race that doesn't matter.

Don't fall into the anti-AI hype argues that developers shouldn't ignore AI because of moral reasons and recommends that every developer should test these new AI tools and see if they are helpful for them.

The 80% Problem in Agentic Coding explains that even though AI can generate "most of the code" quite easily, generating "the rest" is a lot more challenging.

Spring AI Agentic Patterns Part 1, Part 2, Part 3, Part 4, and Part 5 is a series of blog posts which highlights the features of the spring-ai-agent-utils toolkit that provides agentic patterns for Spring AI.

Some thoughts about using AI-Coding tools argues that while AI tools can generate decent code, they don't necessarily increase the productivity of an experienced developer.

Stepping into Crazy AI World argues that developers should pretty much ignore AI hype and concentrate on learning how they can use AI tools for delivering software faster than ever before.

Software Development

Software craftsmanship is dead argues that software development projects tend to favor speed and short-term metrics over writing high-quality and maintainable code.

21 Lessons From 14 Years at Google identifies the software development lessons gathered from 14 years at Google.

How Dependabot Actually Works describes how Dependabot identifies the required dependency updates and creates PRs.

The Next Two Years of Software Engineering identifies five crucial questions that will define software engineering for the next two years.

YAML? That’s Norway problem is an interesting and funny post which explains why the country code NO is parsed as false.

Why Senior Engineers Let Bad Projects Fail explains that sometimes the most "senior" move is to stay silent and let a flawed project fail.

Make It Make Sense argues that massive failures happen when the meaning of data or UI is left implicit.

Checked exceptions and lambdas identifies three different approaches which help us to use checked exceptions with lambdas.

What’s New in Maven 4 highlights the key features of Maven 4.

Towards faster builds describes how the Quarkus team improved the build time of Quarkus applications when they got feedback that the build time was noticeably higher than the build time of a similar Spring Boot application.

Software Design Principles That Matter identifies three software design principles which help us to build flexible and maintainable code.

Spring Boot Debugging – Now Remote describes how we can debug a remote Spring Boot application with IntelliJ Idea.

Data-Oriented Programming for Java: Beyond Records introduces the next phase of data-oriented programming for the Java programming language: carrier classes and interfaces.

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

    

Let's begin!

Test Design

AI-generated tests as ceremony argues that if we use AI to generate tests after writing our code, we reduce testing to a hollow ceremony and miss the opportunity to see the tests fail before they pass.

Buying the Right Test Coverage (With a Deductible) suggests that we should treat automated tests as an economic trade-off and write only the tests which have an acceptable return of investment.

Back to the basics: Rethinking how we use AI in testing argues that AI should be used to support, not replace, human expertise and domain knowledge.

Testing for Quality, Betting on Value explains that even though testing can verify if a product works, it cannot ensure that we have built the right thing.

Stop Chasing 100% Coverage: A Pragmatic Frontend Testing Pyramid argues that we should concentrate on writing the correct tests instead of chasing the 100% test coverage.

Automation Is Not Quality, And Never Was explains why automated tests don't help us to create "quality".

Designing API Test Coverage for Microservices argues that we shouldn't rely on high test coverage percentages. Instead, we should select the required test cases by doing risk-based prioritization.

Flaky Tests: a journey to beat them all defines the term flaky test and identifies three methods the author used to eliminate them.

The Thing Everyone Misses About Tests argues that writing tests helps us to become better engineers.

Backend

Rethinking Spring Application Integration Testing argues that Spring integration tests should shift from traditional horizontal slicing to vertical and functional slices.

How to Execute Tests Selectively in TestNG explores multiple strategies for re-running failed TestNG tests.

Revolutionizing Integration Testing with TestContainers: A Modern Enterprise Approach explains how we can use Testcontainers for running "real" external services which are used by the system under test.

Custom JUnit 5 Extensions for Testing explains how we can simplify our test suites by writing custom JUnit 5 extensions.

Testing Emails with Testcontainers and Mailpit describes how we can write end-to-end tests for code that sends emails.

Introduction to Behavior Driving Development with Java and MongoDB describes how we can write BDD tests for MongoDB repositories with Java and Cucumber.

UI / End-to-End

Automating Push Notification Testing with Appium describes how we can write tests which ensure that push notifications are sent and received correctly.

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

   

Related Stories

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

 

Let's begin!

AI

Does AI make engineers more productive? It’s complicated argues that even though AI helps us to write code faster, it may not improve overall productivity.

The Specification Renaissance? Skills and Mindset for Spec-Driven Development argues that as AI-generated code becomes more common, our ability to write clear specifications that define what we want to build becomes the new bottleneck.

My 2026 Coding Stack highlights the author's AI coding stack for 2026. The author's goal is to maintain flexibility and avoid being locked into a single provider.

From Autocomplete to Co-Author: My Year with AI reflects on a year of using AI and explains how AI evolved from a simple autocomplete tool to a co-author which generates code that requires minimal changes.

On insight debt argues that if we concentrate on shipping features without understanding why they work, we take "insight debt" that makes our code hard to change.

Make your PR process resilient to AI slop argues that AI-generated code isn't a problem as long as we have a proper code review process.

AI Coding Tools Are Not the Problem, Lack of Accountability Is argues that the issue with AI-generated code is the lack of accountability when developers ship code without understanding and reviewing it.

2025: The year in LLMs summarizes the AI breakthroughs of 2025, and highlights the shift toward reasoning models and autonomous agents.

Software Development

A Central Conflict in 'Readable' Code argues that if we want to make our code simpler, we must be ready to make it less familiar (temporarily).

gRPC in Spring Boot describes how we can use the Spring gRPC project for implementing gRPC endpoints and explains how we can write a gPRC client that invokes our new endpoints.

API Versioning in Spring identifies five strategies for implementing API versioning in a Spring Boot web application.

Next level Kotlin support in Spring Boot 4 describes how Spring Boot 4 makes our life easier when we are writing Spring Boot applications with Kotlin.

The Ultimate Guide to Successfully Adopting Kotlin in a Java-Dominated Environment introduces a five-part tutorial that helps Java developers to adopt Kotlin. This tutorial addresses both technical and organizational challenges which we might face during this transition.

The best way to use the Spring @Transactional annotation provides a quick introduction to the @Transactional annotation and describes how the author uses it to configure transaction boundaries.

A Philosophy of Software Design vs Clean Code documents the debate between Robert "Uncle Bob" Martin and John Ousterhout on what's the best way to write clean code.

Logging sucks. And here's how to make it better explains why traditional logging sucks, and describes how we can solve this problem and make our logs useful again.

CS Books I'll be reading in 2026 highlights five books the author will read in 2026.

Write code that you can understand when you get paged at 2am argues that if we want to prevent on-call disasters, we must prioritize simple and readable code over "clever" abstractions which are impossible to understand in the middle of the night.

The Case Against Microservices argues that for most organizations, the drawbacks of micro services outweigh their benefits when compared to a well-structured monolith.

The post Software Development Monthly 12 / 2025 appeared first on Petri Kainulainen.

   

Related Stories

• Software Development Monthly 4 / 2026
• Clean Test Automation Monthly 3 / 2026
• Software Development Monthly 2 / 2026