Blog about programming, good practices, thoughts

Tips for optimizing integration tests

While unit tests are known for their speed compared to integration tests, the latter offer heightened confidence in the system’s functionality. Thus, avoiding integration tests is not advisable; instead, it’s crucial to strike a balance by writing tests at an appropriate level to ensure high confidence in the codebase. Achieving this equilibrium between time efficiency and confidence is paramount. Rapid feedback is essential for a smooth workflow, and today, I’ll share concise tips to enhance the efficiency of your integration tests. The effort invested is worthwhile, as swift feedback is indispensable for seamless operations, and each minute of improvement is magnified by the frequency of executions and the number of developers in the company.

Uncovering the bottlenecks: An investigation into the poor performance of Laravel’s container

Last time I’ve been analyzing the performance of Laravel’s container. I’ve encountered that the application spends a lot of time building dependencies, especially for heavy endpoints. That was strange because I would rather expect the relevant logic should be the heaviest part of the request.

Laravel – AggregateServiceProvider affects the performance

Some time ago I started wondering about the long bootstrap time of an application based on Laravel. I’ve started debugging and have figured out that this problem was related to the lack of deferred providers. It was strange because we’ve used a lot of deferred providers. After more debugging, we’ve found that AggregateProviders doesn’t respect deferred providers.
Read More

Laravel – variadic parameter trap

What do you expect from the framework if the dependency cannot be created? Sure, it should be an exception, but I had an unpleasant surprise.

Modeling a future action

During modeling a business logic we have often a problem with properly highlighting a relevant future action. I mean relevant from a domain point of view. The most popular solution will be using a CLI command which will be executed by cron at a specific time. I think that this solution often hides a lot of business logic in an inappropriate place. Perhaps, there is a better way?

An absolutely clean domain or just common sense

Nowadays, a concept like DDD is widely known and used by many programmers. Curious programmers read a lot about those practices in books written by Evans or Vernon or maybe have knowledge from conferences or blogs. As I saw many times, people are trying to be too much strict with these practices. Trying to make a domain completely clean is of course highly desired, but if you have a not very complex domain, and to have a completely clean domain you need to highly complicate the code around it (probably Infrastructure’s code) something is wrong, don’t you think? So you need to think about the return on investment. Is it worth having more work to do, and complex infrastructure code to just make your domain completely clean? In most cases probably it isn’t at all, only in projects with a highly complicated domain it will be necessary to define a core domain, and then perhaps making this core domain completely clean will make sense. However, not every place in your project will be perfect, you should invest your time only in the most important places. So in this article, I would like to write about using ORMs when approaching DDD which are often hated by many people.

Unit testing tips by examples in PHP

In these times, the benefits of writing unit tests are huge. I think that most of the recently started projects contain any unit tests. In enterprise applications with a lot of business logic, unit tests are the most important tests, because they are fast and can us instantly assure that our implementation is correct. However, I often see a problem with good tests in projects, though these tests’ benefits are only huge when you have good unit tests. So in these examples, I will try to share some tips on what to do to write good unit tests.

Docker hangs during build

Yesterday I had a strange problem with Docker during a build process. I use Linux Mint. I didn’t have enough space at the main system directory /. By default, Docker saves all data (images, volumes, etc.) in /var/lib/docker. Firstly I wanted to move this directory to the /home, but unfortunately, there was probably a problem with encryption, and Docker’s daemon couldn’t start properly. The second option was to move the directory to a hdd drive. But it also wasn’t a piece of cake (just Linux user normal day 😀 ).

Circuit Breaker

In most systems, we use remote calls. Many factors may have an impact on these remote calls e.g. network latency, server availability and so on. So we should assume that something can go wrong. These calls can be potential bottlenecks, we don’t want user waiting for the response from the server very long, because external API is very slow or not available. Also if we have a few services which communicate with each other we shouldn’t aggravate the situation when one of them has too much traffic and slow down significantly. So how to do it correctly?

Mutation testing – we are testing tests

Writing tests should assure us that the code created by us is working correctly. Often we point out the code coverage factor and if we have 100% we can say that implemented solutions are correct. Are you sure? Maybe there is a tool that can give us more accurate feedback?