I wrote about WireMock last year. It's a very powerful tool that lets us replace external services with stubs while testing. Since it can be configured on the fly by tests, it allows us to validate virtually any behavior. Here's how I use it:

In this sequence diagram, a test tells WireMock to return a JSON body for every request to /fetch-details. During execution, the test calls /some-endpoint to validate it. This endpoint needs data from an external service to produce a response, so it requests /fetch-details and gets the JSON body that the test fed WireMock at the start. By changing what /fetch-details returns, we can easily simulate various scenarios.

In this post, I want to cover a case I dealt with recently: form data with decimal numbers.

Awaitility is an excellent Java library. It's especially useful for working with eventually consistent APIs. For instance, when a client sends a POST, PUT, or DELETE request, you might need to make several GET requests before observing the changes, which is terrible for automated tests. A common solution to this problem is to use Awatility. You can ask it to execute code for n seconds until the request succeeds or the timer expires.

await()
    .atMost(Duration.ofSeconds(5))
    .until(() -> apiClient().get(id).getStatus().equals("expected"));

Unfortunately, the default error messages could use some work.

Photo by Mike

Postman has long been, and continues to be, an industry standard for API testing. Numerous beginner courses for QA engineers dedicate sections to explaining how to use it. Software developers, product owners, database administrators, and many others often have Postman installed as well. Another prominent tool is Insomnia.

Both, unfortunately, push their users to create accounts and share often commercial information with their cloud services. I don't mind online collaboration, it can be really helpful, especially in large teams. However, I dislike when perfectly capable products start introducing artificial barriers that persuade customers to use features they don't need and never asked for. Do I need a cloud workspace to work on a course project? No. There's a term for that: enshittification.

A few months ago, I discovered another API client called Bruno, which offers a healthy alternative.

Playwright is a relatively new automation library for browser testing. Despite that, it has already gained some user base, with articles and tutorials regularly appearing on Software Testing Weekly. It comes with many features necessary for UI tests, but crucially, it can also work with API requests made by the web app under test. This allows us to either completely mock responses from a backend server, or alter them - depending on what we want to achieve. In this post, I will show how to do both things in Java.

In March, I wanted to add code generation to a project I was working on. I had a publicly available OpenAPI contract of considerable size, and using it I needed to integrate with a third-party service. I decided to stick with the generator I was already familiar with. Unfortunately, it was incompatible with the specification at my hands!

When I created this blog last summer, I had several goals in mind: to acquire new skills, learn about fresh technologies, and have fun in the process. Its simplicity allowed me to rewrite the project multiple times using different programming languages and libraries: Rust with Axios, Java with Next.js, Java with Thymeleaf, and finally, Golang with React. While the first two options reduce the amount of code by handling both the service logic and the HTML rendering, they also take on too much responsibility in this way. Not that this is wrong by definition, but I prefer to separate these concerns.

However, this approach increases the workload. I had to build models on both sides, consider not only the controllers but also the client implementation, where changes on either side can break the integration. In this post, I want to explore a way to eliminate this overhead and explain how to generate code for a Go server and React client based on an OpenAPI specification. The idea is not limited to this stack, it can be easily applied elsewhere with suitable tools.

The full demo project is available on GitHub.

It might be hard to find a fully independent service today. Even in the case of a monolithic architecture, where all components of the software are tightly coupled within a single codebase, there's still a need to integrate with the outer world. For instance, internal banking logic can be self-sufficient. But functionalities like police security checks and interbank money transfers can't be done in isolation.

During the development phase of a product or feature, programmers may write stubs and mocks to substitute missing dependencies. As QA engineers, however, we want to test the code that will go into production, touching the same statements and execution paths as the real data. Furthermore, we need to validate the system's behavior with various inputs, hence it should be possible to change how the external service responds to the program under test.

WireMock is a tool that enables us to do exactly this. It launches an HTTP server that can be configured to respond to specific requests in a desired manner. Let's say there is a system that should verify the recipient's IBAN against a database. If the response is positive, the transfer proceeds; if negative, the transfer must be blocked.

This year, I decided to ditch Postman. It had started pushing cloud integration up to an extent, where working without creating an account became nearly impossible. Many features were disabled in the "lightweight" mode. From a privacy perspective, I could have created an email alias, but I wasn't happy with the overall direction of their development. Why invest time in a tool that is likely to become less customer-friendly and accessible in the future?

A few weeks ago, a potential employer asked me to complete a test assignment. The task was to implement a bunch of API and UI tests. This requirement is quite standard in the field, but I had not previously compiled any work ready to be shared alongside my CV.

Therefore, I made the decision not only to complete the assginment but also to document and explain it here in this blog post.