All language subtitles for 012 Working With Mocks_en

With help of defined queries,

we are able to wait for our data to be rendered.

So this generally works,

but this is still not ideal here, this test.

Why is it not ideal?

Because we are sending a Http request here.

And in this case

we are fetching some data from some API.

However, when we run our tests

which we typically do a lot during development,

we

generally don't wanna send

Http requests to our servers.

We don't wanna send requests

because A, that will cause a lot of network traffic,

it will hammer our servers with requests.

Especially if you have a lot of tests

with a lot of requests.

And B, if you are not fetching data

but you have some Component

that sends a post request to a server,

your tests might start inserting data into a database

or they might start changing things on the server

because of course you also wanna test Components

and scenarios where such kind of requests are being sent.

And that's definitely not something

you wanna do during testing.

You don't wanna send requests

to servers that start changing things there.

So therefore what we generally wanna do

when we write tests is,

we either don't even wanna send a real request

or we wanna send it to some fake server,

some testing server.

Both are viable approaches

and I'll go for the approach here

where we don't even send the request in the first place.

Because there's one super important thing to note,

when you write a test

you don't wanna test code, which you haven't written.

So in this case, I don't wanna test

whether this fetch function works correctly

and sends a request.

The fetch function was not written by me,

it's built into the browser.

I rely on the browser vendors

to have written that function correctly.

So therefore I don't wanna test whether fetch

successfully sends a request technically behind the scenes.

I instead wanna test if my Component behaves correctly

depending on the different outcomes of sending a request.

So I wanna check if my Component behaves correctly

once I got the response data.

I maybe also and wanna check

if my Component behaves correctly,

if they got an error.

But I don't wanna check

whether technically sending this request succeeds.

And therefore we wanna replace this fetch function

which is built into the browser

with a so called mock function.

With a dummy function that overrides the build in function.

A dummy that does what we want

and that does not send a real request.

So did when our Component executes during testing

we use that dummy function,

that mock, instead of that real built in function.

That's what I wanna do here.

Now, how can we replace fetch with a dummy function?

This is such a common scenario

not just for fetch,

but also for something like

working with local storage, for example.

Where you also don't wanna trigger changes

in the actual storage.

This is such a common scenario that Jest,

this testing tool which we're using under the hood

has built in support for mocking such functions.

And it's therefore fairly easy to do.

When we arrange our test here

in our Async.test.js file,

here I now wanna override

the built in fetch function with my own one.

And for this, I can reach out to the window object

which will be available here.

And then there is this fetch method.

If I call fetch like this in my Component

I am just using that window fetch method.

So therefore now we can set window fetch

equal to a new function defined by us.

And here we can use Jest,

this object is globally available in our testing code,

it is made available by this tool named Jest,

which runs our tests.

And Jest, this object has a couple of utility methods.

It has the FN method for example.

And what FN does is

it creates a mock function as you see here.

So it creates a dummy function for you.

The difference to just creating a function on your own

is that this mock function

then has some additional features which you can use.

And you'll see those features in action in a second.

So now I did actually override

this built in fetch function

with my own dummy function.

Only of course, in my testing code.

Now, since this is created with Jest FN,

we can again use this mock function which we have now

and call special methods there.

Here even though I'm not getting all the completion for that

we can call mock resolved value once.

What this does is

it allows us to set a value,

this fetch function should resolve

to when it's being called.

And it should resolve to something

that is then used here by our code.

So when this fetch function is called here,

it showed in our case, resolve to an object

that has adjacent method.

Because here we are working with that resolved value.

In this then block we work with the resolve value

of this function called here

of that promise return, but it function call.

And then I'm calling JSON on that resolved value.

So this is the resolved value

we now wanna set here

and therefore I'll set this to an object here.

The object resolved by the promise,

which will automatically be returned

when you call mock resolved value once here.

And then here, I wanna make it clear

that we have a JSON property.

Here this one, which actually holds a function as a value,

so that calling it as a function

as we do it into Component works.

And that will be a Async function actually

because JSON returns a new promise

that's the case for the built in fetch function

and that therefore should be the case

for our mocked fetch function.

And then here it's up to us which value we wanna simulate

that should be returned.

And here in my case,

I actually wanna return an array when JSON is called

and this promise here resolves.

Because data here in this case

is in array for this API end point for this Component.

And that stand as array full of posts.

And every post should have an ID and a title.

And therefore to simulate the success case here

I wanna return an array with at least one post

with an ID of P1, let's say

and

a title of first post.

And now with that code,

we are overriding the built in fetch function

with our dummy fetch function

where we set the actual value this promise should return,

with help of these Jest features.

And if I now saved it all

my tests rerun and they still pass.

But now we are simulating this success case here.

We are simulating this success case

and we're not actually sending

a request to the API.

And therefore we're not hammering that API,

we're not sending unnecessary requests.

We are reducing the amount of network traffic,

we also avoid potential problems if the server is down

and our tests would fail for that reason.

Which of course is not something we want

and we can control different outcomes

for this fetch function to test different scenarios

with our tests here.

And that's why in such cases using a mock

is not a bad idea.