Alejandro Celaya | Blog

A couple of years ago I wrote about how to capture code coverage in API tests. In that article I explained the implications of code coverage collection when the code under test does not run in the same process as the test itself. However, the process explained there was a bit hacky and limited to AP…

Recently ReactJS v18 was released. I started to look into its improvements, and checked which of my projects could benefit from them. The main react-based project I maintain at the moment of writing this article is shlink-web-client, so I naturally created a new branch and started the process. The u…

You can find an improved version of what's described here in Capturing remote code coverage in E2E tests with PHPUnit Capturing code coverage for a test suite is a very useful way to know which parts of your source code are actually getting executed by tests. This is useful not only to know if you…

For a long time, I have been trying to include tests in every project in which I've worked on. There are several types of automated tests (or what should actually be called automated checks). From unit tests, integration and functional tests, to end-to-end tests. Each one of them differs from the re…

There's no doubt that having tests in a project allows you to find potential bugs earlier and more easily. Lots of OSS projects require a minimum code coverage in order to accept new pull requests from contributors, and proprietary projects also tend to have some sort of continuous integration workf…

Docker is, without any doubt, the trending tool these days. Everybody wants to use it, because it is very useful, allowing to easily generate development environments for any kind of application. A couple months ago I started working with docker myself (it has taken me a while, I know), and now I ca…