In one of our core services, the execution of a single unit test took approximately 30 seconds, while a single integration test ranged between 65 and 70 seconds. Running the entire test suite took circa 6 minutes.
Are you, as a test automation engineer, tired of Selenium’s flakiness? Are you seeking a better tool to automate your end-to-end tests? Have you heard of Playwright? Perhaps you’ve encountered opinions that it is only worth using within a Node.js environment. I have. And as a tester, I decided to verify if this is true. If you’re interested in the results, I encourage you to read the following article.
The purpose of this article is to present how to design, test, and monitor a REST service client. The article includes a repository with clients written in Kotlin using various technologies such as WebClient, RestClient, Ktor Client, Retrofit. It demonstrates how to send and retrieve data from an external service, add a cache layer, and parse the received response into domain objects.
A picture is worth a thousand words — see for yourself how this unique Agile team learns BASIC from their Product Owner.
Have you ever worked on a project where after downloading the code from the repository you start to wonder what business requirements are hidden under the layer of unreadable tests? Or maybe you are currently wondering how to test a new feature that you have been entrusted to implement?
Maybe it’s another “How I’ve changed my worklife” story, but I hope it is an interesting one. It seems quite important to tell: before the beginning of my Allegro adventure, I was working as… an archaeologist. It was both physical work on excavations and research work at my PhD studies. And the only thing that connects my past work and the current one is: attention to detail.
Spring is one of the most popular JVM-targeted frameworks. One of the reasons why it has become so popular is writing tests. Even before Spring Boot era, it was easy to run an embedded Spring application in tests. With Spring Boot, it became trivial. JUnit and Spock are two most popular frameworks for writing tests. They both provide great support and integration with Spring, but until recently it was not possible to leverage Spring’s @WebMvcTest in Spock. Why does it matter? @WebMvcTest is a type of an integration test that only starts a specified slice of Spring Application and thus its execution time is significantly lower compared to full end-to-end tests. Things have changed with Spock 1.2. Let me show you, how to leverage this new feature.
Application release process, or in fact software development process, as a release is the final stage of application development, is not an easy thing. Books and IT websites discuss many approaches and each has its supporters and opponents. On the one hand, you have product owners, project managers and customers who want a ready-to-use application as soon as possible. On the other hand, we developers and testers, would like to release an application of the highest quality, which may affect the delivery time. Balancing these needs is a hard nut to crack. Usually, both sides need to make some compromises to establish a common way of working. For developers and testers, it involves answering several questions concerning software development methods, skills, use of manual or automated testing, and storage of test cases and test logs. In this article I describe best practices and tips for starting a new project. I think that by following them, you will make the software development process as effective as possible and adjusted to conditions of your project.
Last year Agile Testing Days Conference was held between 6th and 8th December in Potsdam, Germany. According to statistics provided by organizers there were around 600 attendants and about 30 speakers in keynotes / workshops. During the whole event around 22 different workshops took place, 9 keynotes and around 30 other speeches / presentations divided into 7 parallel tracks. I had the opportunity to attend the first two days of the conference and in this article I’d like to share with you a short review of the most interesting sessions and my impressions about the event.
We’re all familiar with TDD, or at least write unit tests for our software, but unit tests won’t check application state after complex UI interactions. If you want to make sure that an application behaves correctly when users interact with it, then you need to write UI tests.
In the team that develops Allegro Recommendation Platform we weren’t happy with our integration tests. Long setup and assertions blocks resulted in a low signal—to—noise ratio and poor readability. These tests were also full of ad hoc variables like 1, ABC, OK or NOK, which caused that it was hard to find a connection between input and output data. Moreover, any change in an API caused changes in many tests.
Today, in an age of great popularity of test automation, we can observe a growing number of different frameworks which allow us to write scripts and programs that simulate human actions performed on the website under test. The most popular solution is Selenium WebDriver framework, which is compatible with the majority of common languages. Broad compatibility is a big advantage of Selenium especially in cases when we have to write some tests integrated to our application project, because no matter in which language we write the application, Selenium probably has an API for that language too. But there are also situations, like writing a standalone test suite, when we can decide which technology we’d most like to use. Taking into consideration this case, let me introduce to you a short comparison of three JDK-based technologies:
SOA (Service Oriented Architecture) as a modern approach to build distributed enterprise applications gives us many benefits, including resiliency and fault-tolerance. On the other hand, there are many new kinds of SOA-specific faults, like publishing, discovery, composition, binding or execution faults (as stated in A Fault Taxonomy for Service-Oriented Architecture). Error handling is one of the most important things to have services right designed and implemented (see article Error Handling Considerations in SOA Analysis & Design). In this article, I want to focus only on a small aspect of this broad subject: unexpected service behaviors which, if not properly handled by the client, can lead to application inaccessibility.
The first question is — what is overmocking? There are a couple of answers. When you mock something that you can leave or even should use as it is — this is overmocking. An example of this is a POJO object. Other way to overmock your test is to mock all the dependencies and rely only on verifying interactions with mock objects. You will see that in my examples. Overmocking can also happen when you mock something that you don’t own like an external library.
One of the major goals of software development, apart from actually delivering the product, is to guarantee it is of proper quality and not prone to errors. Big modern systems tend to consist of dozens of smaller pieces, often accompanied by some legacy core or part of legacy system. Each of these, often very different pieces of software communicate with each other in some way, in synchronous or asynchronous way, through REST endpoints, SOAP services or a variety of messaging systems. This leads to new challenges. A failure or unexpected change in one place may lead to a misbehaviour in other parts of the system.
If you are an agile developer who is fluent in multiple languages, you understand the importance of testing. You have several types of tests (unit, integration or behavioural) at your disposal to check your application. The number of available tools, frameworks and even languages is enormous, just to mention a few: Junit, Geb, jBehave, Cucumber, Spock, Selenium. Dozens of other tools can help you verify whether your code is working properly. Besides, I assume you are familiar with TDD and BDD methodologies which are rather standard nowadays. Nevertheless, all of these tools have common limitations – they check your test environment only. Let me show you how one of Allegro teams responsible for the Offer Listing tests the production environment.
REST (Representational State Transfer) has become very popular over the course of the past few years. It has happened so not only because of growing popularity of lightweight Web frameworks (like Angular.js) but also due to the new Microservice Architecture hype (thank you Netlifx). Frameworks like Spring add new REST-related functionalities with each new release and more and more companies decide to give them a try… But how do you test them - REST services and their clients?
Introduction This article is addressed mainly to people who are not very experienced in the area of unit / integration testing although basic knowledge of JUnit is required. I am going to provide you with a quick recap of the most commonly used Java testing tools, starting with JUnit (together with three nice complementary libraries: JUnitParams, catch-exception) and Mockito. Then I will show you how to perform assertions in a much nicer and cleaner way using AssertJ so that you never have to use Hamcrest again.
