In the early nineties I used to fall asleep to the fuzzy glow of the monochrome amber monitor of our tired 80286 and the murmur of its busy hard disk, compiling and linking my dad’s code written with Borland C. Some nights they would be accompanied by the comforting clacks of his IBM Model M keyboard. It wasn’t a big apartment, and my bedroom was the only place with enough space to set up his home office. Or maybe he wanted to draw my attention to those fascinating machines — which he successfully did.
Back then he used to work for a company that manufactured telecommunications equipment. He did — and still does — refer to himself as a programmer. …
In this article we analyze differences of the restore, reset, resetHistory and resetBehaviour functions in sinon, and how they behave depending on whether our sinon fakes are anonymous or they wrap existing properties.
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 have it called just once as part of the second unit test, but it turns out the call count from the previous unit test was not properly reset, and the value of the spy’s callCount is 3. …
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 JBoss CLI, which is crucial to improve the startup times. …
Deep equal assertions are faster to implement but usually come with a dangerous lack of attention
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?
Consider a person object that results from a transformation function with some business logic inside it. …
Asking this question might be a sign of underlying design flaws. And the first step to fix them.
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 point: redundancy. And despite being valid points, they are more suited for actual object oriented programming, an aspect where JavaScript is not quite there yet. …
ES6’s spread operator makes deep merging easier than ever
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 fastest promise in JavaScript is the one that has already been resolved!
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; instead, the pending promise will be recycled and used again in any subsequent call. …
Exploring scenarios in which we might want to deviate from the standard.
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 include sensitive information. …
With the package “pending-promise-recycler”, we can save precious resources and avoid performing the same operation again and again by recycling pending promises.
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 list endpoint at the same time? …
And non-programmers too!
I’ve always considered my work-related memory to be subpar.
I would often be asked whether I remember how we implemented X or why we chose option Y; and even though we did implement X and chose option Y three or four times, the answer would forever remain hiding on the tip of my tongue and never show up. This here is a terrible feeling that would make me feel really incompetent.
One might retort: “Well, why didn’t you write down those oh-so-important things somewhere?”
I did. But I eventually forgot where. And the answers would change their hiding place from the tip of my tongue to some drawer swamped with papers and post-its or a text file amongst dozens of text files in my hard disk. …
About
