Scoping Jest tests

I'm a full-stack developer from South Africa 🇿🇦. I love writing about JavaScript, HTML and CSS.
Search for a command to run...

I'm a full-stack developer from South Africa 🇿🇦. I love writing about JavaScript, HTML and CSS.
No comments yet. Be the first to comment.
Most of you know me for my consistency, a golden arrow in my blog series. I've written 1000 articles in 1008 days! Almost an article a day, and my honeymoon was the only holiday I ever took. I'm super proud of this achievement; it has been a fantasti...

It's not the first time I'll be talking about community. I think it's an essential aspect of any successful tool. This shows in my previous explorations of Astro, Medusa, and now Vendure as well. All these products thrive in a super open, welcoming, ...

The cool part about Vendure is how easy it is to set up and how abstract each layer is. Basically, we get the following elements: External database Server Worker Admin UI Frontend While this is amazing, it also brings a bit of complexity when it co...

The previous article looked at customizing Vendure on a data and process level. In this article, we'll look at customizing emails, as they are often a big part of a webshop system. We'll be looking at two different layers of customization for customi...

Even though Vendure is a pretty significant project out of the box, in some cases, we might want to go in and modify some elements to work to our specific use case. In this article, I'll take a high-level look at some elements we can customize within...

So far, we only looked at tests executing on the highest level. All tests are basically in the same scope.
But Jest gives us the option to scope down. This can be super easy for recurring tests setup.
For instance, in the previous article, we learned about Jest recurring actions, which are prime examples of use for scoping.
To define a scope in Jest, we can use the describe function to wrap all our tests.
describe('user related actions', () => {
test('Create new user', () => {
expect(createUser('Chris', 'p4sSw0rD')).toBe(true);
});
test('Update user', () => {
expect(updateUser(1, 'Chris new name')).toBe(true);
});
});
Now, these two tests will run inside this scope, and besides it being nice to organize, we get some added benefits of this scope.
For instance, this scope can get its own recurring actions. These defined actions will only fire for this scope. However, global scope-defined actions will also fire!
For instance, let's say we have a public database, but for one section, we want to apply a hobby database as well.
beforeAll(() => {
return createDatabase();
});
beforeEach(() => {
return populateUsers();
});
afterEach(() => {
return clearUsers();
});
afterAll(() => {
return removeDatabase();
});
test('Add a new user', () => {
expect(addUser('Chris')).toBe(true);
});
describe('hobby related tasks', () => {
beforeEach(() => {
return populateHobbies();
});
beforeEach(() => {
return clearHobbies();
});
test('Add a new hobby', () => {
expect(addHobby(1, 'Photography')).toBe(true);
});
});
Let's run this code and see what gets called to see what happens.
As you can see, a complete riddle of executions, but it's essential to look at the before each and after each fire order.
The scope can also be used to define and overwrite variables that you might use.
For instance, we might have a different logged-in user for whom we want to write test cases.
describe('user related tasks', () => {
const loggedUser = 1;
test('Add a new user', () => {
console.log(`adding new user: ${loggedUser}`);
});
});
describe('hobby related tasks', () => {
const loggedUser = 2;
test('Add a new hobby', () => {
console.log(`adding new hobby for: ${loggedUser}`);
});
});
As you can see, we define the loggedUser twice, and the output of this sequence would nearly be as expected:
I hope this gives you an excellent first introduction to defining scoped test blocks.
Thank you for reading my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter