If you are not working with multithreading programming and don’t have to test any asynchronous code then this post will probably do you nothing good. But if you have ever struggled with testing some logic running in multiple threads and you don’t know Awaitility. A small library helps testing asynchronous code. If you’ve never heard of it then you should continue reading.
Mocking library is an important tool in every developer toolbox. Sometimes you want to do things that at first glance look a bit more complex than returning number 42 from some method. Let’s see what stubbing techniques are available in Mockito out of the box and what they offer.
We are improving cache in the project Im working on. In the code base I’ve found a method which accepted a collection of ids and returned collection of objects for those ids. My goal was to add cache on individual values returned by the method. Creation of items was IO heavy and time-consuming operation so removal of cache was not an option.
In the past, I’ve implemented couple of tests that aimed to verify naming conventions or some other practices team agreed upon. And presented a way how to ensure they are followed. When I’ve been writing those I was not aware that there is a library that aims to test architecture conventions - ArchUnit in this post I’ll write a simple test case to check what’s possible out of the box.
Recently I’ve found a very interesting project which allows to spin up docker containers for test purposes. Writing tests checking integration with external services is not an easy task. With testcontainers library it gets simpler because you can have external service up and running just for your test in a couple of lines of code.
Recently I had to set up some extra logic to be executed before running tests. I had two options - create yet another abstract class with some behavior or somehow extend Spock and introduce extra logic to be executed just before actual test starts. As we already have enough of abstract classes I decided to try and do the second option.
Some time ago I’ve faced a very interesting support issue. Long story short it turned out that one of our applications was not connecting to proper service and as a result, it’s been displaying invalid data to users. After a bit of investigation, I’ve noticed that spring’s configuration mechanism did fallback to default value because of missing configuration key for the production profile. In this post, I’m going to present to you how we are going to avoid similar issues in the future.
Have you ever wondered how it’s possible that spring-boot is able to pick up whatever you have on
the classpath and configure application context to your needs based on some conventions and bit of
black magic? In this post, I’m going to dig into
spring.factories file on which most of the
spring-boot power is based.
How to introduce automated checks that will guarantee that conventions are followed in an example of test naming convention. I’m going to focus on creating automated process that will verify if test names do match conventions. Automation will allow us to forget about the rule because the computer will ensure it’s followed. Test that I’m going to introduce will be living documentation inside the project and ensure no one will miss nor forget about the way we group tests.