Our CI Doesn't Do Weekends

󰃭 2026-01-24

I think a codebase can tell you a lot about the people that work on it. From this specific example in particular, I felt very reassured that the team takes work-life balance seriously and never works on weekends.

For context, the software interfaces with old-school banking systems that famously do not run certain processes on holidays or weekends.

We had some logic to to an early return to avoid running a process on bank holidays, imagine something like the following:

if (isBankHoliday(new Date())) {
  logger.info("Skipping process on bank holiday");
  return;
}
// ... continue business logic below

This logic was not covered by any tests! Not to say that there were no tests, but they were more focused on what would happen on work days and not the fact that the code should not run on bank holidays.

This worked quite well, until somebody pushed changes on a weekend.

Weekends are considered bank holidays, so the check to avoid running on bank holidays was triggered and the tests failed. Fortunately, the changes being pushed on the weekend were not urgent and nobody was blocked by this.

The lesson we learned from this is that you should not work on weekends!

Although in all seriousness, the tests should have faked the date from the start to avoid this. Even if people are not working on weekends, it could be that they work in a different timezone, or the team needs to push an urgent hotfix during the weekend.

The way to do this using vitest is very simple:

// Pick a date that is definitely not a bank holiday!
vi.useFakeTimers({ now: new Date("2025-03-03"), toFake: ["Date"] });

By the way, vitest is very fast and very easy to migrate to from jest! Make the switch if you haven’t already!



More posts like this

Using AsyncLocalStorage for Better Traceability in NodeJS Applications

󰃭 2024-09-29 | #javascript #nodejs #tutorials

NodeJS has a neat API called AsyncLocalStorage. It’s used to share information across callbacks and promise chains. For example, it is useful to share information for all the code executed when serving a web request. I also found it very useful to keep trace information to easily keep track of which item was being processed during a batch process. The only caveat in my opinion, is that you need to wrap your code in yet another callback.

Continue reading 