A very common approach while working with sinon, as shown in their own documentation, is to call the function restore as part of Mocha’s afterEach hook.

afterEach(function () {
    // completely restore all fakes created through the sandbox
    sandbox.restore();
});

This should be enough to make sure everything is back to normal when a new test starts, and they don’t influence each other, right? Well, this is sometimes not the case.

Let’s have a look at the following example:

Looks like restore did its job fine except for the call count of the log.info spy. We were expecting to…

If you have offline sessions enabled in Keycloak and there are lots of them stored in the database (e.g. more than 300k) you will notice that the time it takes to start up can be up to more than 20 minutes. In this article I will share some tips we implemented to make it go faster. In our case, we managed to start up with 750k offline sessions in 2 only minutes 58 seconds, instead of ~15 minutes!

I will also explain how to programmatically change the value of the property sessionsPerSegment, both in the XML configuration and using the…

Has anyone in your team ever said something like this? “It was covered by unit tests, but we were comparing it against the wrong value!”

Most of the times I’ve heard that, there was a deep equal assertion involved. Deep equal assertions in Chai.js are extremely simple and fast to implement — why write assertions property by property when I can just do a deep comparison of an object that I can easily copy-paste in my tests? — but by doing so, developers miss the chance to ask themselves: is the value of this property what it really should be?

…

Why you usually shouldn’t test them

In her book Practical Object Oriented Design in Ruby, Sandi Metz enumerates the following reasons not to include private methods in unit tests:

• Redundancy: private methods are hidden inside public components that already have tests; a failure in them will always be exposed by an existing test.
• Instability: private methods are more likely to change, and when they do, so will the tests. This costs time.
• Exposure: testing private methods exposes them to a bigger audience who might be misled into using them, therefore breaking encapsulation by depending on them.

I can say I only wholeheartedly agree with the first…

Since the spread operator was released as part of ECMAScript 6, I haven’t looked back at other approaches to deep merge objects. It’s easy, readable, and fast:

const merge = { 
    ...objectA, 
    ...objectB, 
    ...objectC 
};

Let’s look at how it’s done with a simple example:

Performance

A performance test with JSBench.me shows the following comparison between merging using the spread operator and the function Object.assign:

The npm package pending-promise-recycler keeps track of promises in a pending state; that means ongoing promises that have not been resolved yet.

If someone would try to create a new instance of one of those pending promises, pending-promise-recycler will reuse the one that is currently pending instead of unnecessarily creating a duplicate one.

How to use pending-promise-recycler?

Simply wrap any function that returns a promise with pending-promise-recycler:

const recycle = require('pending-promise-recycler');const func = () => { return Promise.resolve(); }
const recycledFunc = recycle(func);recycledFunc().then(...);

Any extra call to recycledFunc while it is still pending will not incur in an extra call to func…

Normally, I’d say “no, you don’t”; because GET is for read operations and POST is meant for write (e.g. create) operations.

But today I was reading the draft of some OpenAPI specifications, in which one of our REST API consumers suggested having a new endpoint to look up users by their phone number. And they wanted this to be a POST endpoint. So I asked myself: why would they want this?

Security reasons

When a get GET request is received, many servers log information about the incoming request. Most of them will log the whole requested URL including query parameters, which might…

Imagine the following scenario.

We have an API that sometimes makes calls to a 3rd party service; for example, to retrieve a list of stores. Let’s assume that retrieving this list of stores is a very expensive and slow operation, averaging a response time of about 12 seconds.

As soon as we get the response, we probably want to cache it somehow so that we don’t make our API consumers wait for so long every time they need to get a list of stores.

But what would happen when 1,000 of our API consumers fire a call to our store…