The Clean Test Automation Monthly is a monthly blog post that shares interesting or useful test automation content that I consumed during the current month. This blog post is always published on the first day of the "next" month.
Let's begin!
Test Design
Unit tests mark territory more than squash bugs argues that the main purpose of unit tests is to prevent other developers from breaking our code.
Registered Is Not Concurrent: How to Pick Concurrent Users for a Load Test identifies a repeatable method for determining a realistic concurrent user count that can be used for load testing.
Test, Heal Thyself! argues that even though AI-driven self-healing tests can reduce the time required to maintain tests, the process that's used to fix failed tests can do more harm than good.
Your Agent-Written Tests Aren't Real Tests explains that if an AI agent generates both the application and the test code, the test suite no longer verifies correctness. Instead, it acts as a contextual map to the code base (for future agents) and simply mirrors the agent's misinterpretations of the requirements.
My tests were green. The product wasn’t describes how even a comprehensive test suite (which had mutation tests) can leave our software vulnerable to critical bugs, because our tests only verify what we decided to check.
The Problem With Your AI Tests warns that AI-generated tests create a false sense of security and identifies four issues that are often found in AI-generated test suites.
AI can generate tests, but can it guarantee their reliability? documents the findings of an experiment where a person with no previous coding experience tried to generate a reliable automated test suite by using an AI agent.
Make your coding agent prove its tests can fail explains that when an AI agent generates both the production code and its tests, the tests can simply mirror the agent's misunderstandings of the requirements. To prevent this, the author argues that we should make an AI agent prove the validity of its tests by demonstrating that the assertions will fail if a bug is added to the production code.
Contract testing implementation challenges identifies four misconceptions the author has encountered when he has helped software development teams to implement contract testing.
Backend
Writing Unit Tests for "Normal" Controllers With Spring MockMvc: Standalone Configuration describes how we can configure the system under test by using the standalone configuration of Spring MockMvc when we are writing unit tests for view-rendering Spring MVC controllers. We will learn how we can get the required dependencies and remove duplicate configuration code from our test classes by using both object mother and HTTP request builder classes.
Writing Unit Tests for "Normal" Controllers With Spring MockMvc: Test Slice Configuration describes how we can configure the system under test by using Spring Boot's test slice configuration (the @WebMvcTest annotation) when we are writing unit tests for view-rendering Spring MVC controllers. We will learn how we can get the required dependencies and configure the system under test.
158 Free (Legacy) Spring Testing Articles explains why I decided to transform the website of the Test With Spring course into a static HTML website.
UI / End-to-End
How to Disable, Exclude & Phase In axe Rules in Playwright describes how we can use Playwright's axe integration to gradually introduce accessibility tests into an existing web application without being overwhelmed by a massive list of violations.
Delivered Twice, Charged Twice: Testing Webhooks with Playwright identifies the unique challenges of testing webhooks and demonstrates how we can write automated tests for them by using Playwright's API testing capabilities.
I Put Jev in a Playwright Browser Testing Loop. It’s fast, but… documents an experiment where the author integrated the Jev AI model with a Playwright-driven browser and let AI choose the next action and evaluate the outcome.