All language subtitles for 011 Testing Asynchronous Code_en

Now I wanna move on

to a more complex scenario that we could test,

a more complex component.

I added this new async component,

and you find that component also attached.

And the component itself is not that complex.

It uses state and it uses use effect.

So that in use effect,

we send the HTTP request to this dummy API

to fetch some dummy posts.

And then these posts are set as state here,

and they are rendered out as a list down there.

Now, if you would start this development server,

you would see something like this

because I don't have any styling

since this is not about the styling at all,

but you see that fetching and rendering these dummy posts

from this dummy API, JSON placeholder works.

Now, that works and here we are, of course,

using some core mechanisms we learned about in this course,

especially use effect for side effects like this.

Now we wanna write tests for this component

because, of course, this is also something

which we typically wanna test,

and there will be a couple of complexities related to that.

Now, for that, let's first of all, add a new file,

async test.js sounds like a fitting name.

And in there, my tests failed because I have no tests yet.

I'll add a new test suite, and I'll name it async component

To have that as a wrapper.

And then in here we can write the actual test code.

Now, I will import the render and screen function

from the testing library.

So I'll grab that import and add that here as well.

And then we wanna create a test,

we wanna write a test where we test

whether the posts are being rendered correctly.

That could be the first test, which you wanna write.

So here I'll say renders posts, that's my test,

or renders posts if request succeeds.

And then here, this is our testing code.

We now, of course, wanna render this async component.

So we should import this async component

from this async file here and render it.

That's our arrange step.

Then we don't really need to act

because rendering it is already everything I wanna do,

since we will then fetch and set posts automatically

because of user fact.

So no other step is required.

And therefore we can now dive into the assertion.

And for that, I wanna check if some list items were rendered

because I noted if list items were rendered,

posts were fetched correctly because otherwise,

no list items would have been rendered.

So therefore, we can reach out to our screen.

And now we'll find out if list items were rendered.

And there are various ways of getting access.

Here, I wanna get access by role

because getting access by role will allow me to find out

if there are list items on the screen,

since list item is a role HTML elements can assume.

To find out about all supported roles,

I also attached a link with more information on that.

So here we could use get by role.

However, since I expect to actually

have multiple list items, we should use get all by role,

because get by role would fail

if we have more than one item with that specified role.

So here I wanna get all by role.

And then the role here is list item.

You find that role in that attached document.

So that's the role by which I wanna select items.

And therefore here, I hopefully have my list item elements

which will be an array of HTML elements.

And the expectation now would be that list item elements,

this array is not empty

because if this array of items is empty,

we know that no items were rendered,

and that of course is not the desired result.

So here I wanna check that this is not empty

so that it does not have a length of zero.

Two half length allows us to check the length of an array,

and here I only care

about the fact that the length is not zero,

so this is therefore my expectation.

And you will typically be able to express your expectation

with different combinations here.

I'm going for this expectation here.

Now, if I saved this and my tests run, however,

you will see that this fails.

You see that this fails

because we're unable to find an accessible element

with the role, list item.

So somehow it fails to get list items.

And to understand this error,

it is important to understand that get all by role,

just like the query methods you have here,

will instantly look for these elements on the screen.

But keep in mind that here we are sending an HTTP request,

which is an asynchronous action.

So therefore the posts are not there immediately.

Instead, this component renders,

and initially it renders with an empty array here,

with an empty array of posts.

So therefore initially, there are no list items.

Then after this first render cycle,

this effect immediately runs.

And then this request is sent.

And once the response is there, the state is updated,

and then this component re-renders,

this time with list items.

But the initial render cycle does not have list items

because there are no posts initially,

because fetching that post data

takes a couple of milliseconds or seconds.

And that's our problem here.

With get all by role,

we immediately get all these items on the screen,

and initially there are none.

Now, there is a simple work around, though.

Instead of get all by role, you can use find all by role.

The difference is that find all by role or in general,

those find queries which you can use

instead of the get queries, these queries return a promise.

Here you get back a promise,

and actually react testing library

will basically reevaluate the screen

a couple of times until this succeeds.

So therefore now, this will then wait for this

HTTP request to succeed.

For find all by role, you can also specify a third argument.

The second argument allows you to set exact and so on.

The third argument is another object

where you can set that timeout period.

The default here is one second.

So if your items are not there after one second,

this would still fail.

Here, the default of one second shuts of flies,

and now we do fetch those items after one second at most.

And most importantly, we don't just look

at the rendered component immediately, but we wait to see

if we can find that item at a later point of time.

Now, I'm getting some red squiggly lines here because

since this returns a promise, we should await this

before we work on the result,

because the result here is a promise, not an array.

Thankfully, your test code can be async.

You can add the async keyword here.

So put in our words, your test here

can actually return a promise.

And then jest, our test runner,

will wait for this promise to resolve.

So it will wait until your test is already done.

And now therefore here we should add the await keyword.

Now, this here is an array,

and now this hopefully succeeds.

If I now save this, the test runs again,

and now we see that we get this success output here.

We are able to successfully render those posts.

And now I reran all my tests by pressing a again,

and you'll see all tests passed here.

So this works, but this actually is still not ideal.