Javier Pérez Anaya

This is the fourth part of our 12-day Advent of Monitoring series. In this series, Checkly's engineers will share practical monitoring tips from their own experience.

One of the biggest challenges in conducting end-to-end (E2E) testing is managing the artifacts created during the process. These artifacts are necessary for asserting specific functionalities. 

For instance, we might want to verify a resource creation ability, but we do not want to:

Assert the deletion of the created entities afterwards, since this could compromise the isolation and single responsibility of the checks. For example, a check that creates and then deletes a resource might fail during the cleanup process. This could result in a false positive.

Keep the entities around. Imagine having monitors that execute this check every 10 minutes. That would mean six entities are created per hour, or 144 leftovers per day. These would keep piling up and require a specific external cron job to keep the room tidy.

In Checkly, it was our decision, as frontenders, that we wanted to keep not only the testing flow but also the maintenance flow as contained within Checkly as possible.

The conception of the method I will show you is an elaboration on top of the low-level API calls approach that we implemented a while back and Nico splendidly showcased in a past blog.

From this point onwards in the article, there will be some heavy TS nerdiness involved, so behold!

This is a factory method that we will use for returning a wrapped API module that will include two extra methods: addToCleanupQueue and cleanup.

The first one is a method that we will invoke during checks to add IDs to an internal pile of pending-to-remove artifact IDs. The second method will be responsible for invoking the cleanupMethod declared module call sequentially with the IDs, present in the cleanup pile.

For showcasing purposes, I will only list a single module here. Note that the fixture would be configurable to pass any http client you might prefer (axios, fetch, or what have you):

As you might have noticed, there are two interesting parts here:

1. The declaration of API modules gets full TS-type inference, so you cannot go wrong there 

2. There is an API fixture global method for iterating the declared modules and invoking cleanup on every one of them.

Reading through the PWT docs, you would notice that creating a fixture involves invoking use to tell Playwright to inject it into our tests and then having the ability to do some additional calls for whatever housekeeping would be needed. This is the cornerstone of our implementation since we leverage that to invoke our API fixture cleanup:

As you can see, all the bloat that would be required to perform garbage collection at the end of each check is reduced to a clean and tidy oneliner to just add the created entity ID to the API module cleanup pile.

The fixture will take responsibility for invoking the clean-up after the check execution is finished.

The Advent of Monitoring, Day 4: Solving E2E Testing Challenges With Checkly's PWT Garbage Collector

Detect

Communicate

Resolve

Monitoring as Code

Developers

Resources

Community

The Advent of Monitoring, Day 4: Solving E2E Testing Challenges With Checkly's PWT Garbage Collector