All language subtitles for 006 Running a First Test_en

So automated testing is a nice feature.

How does it work?

As I mentioned, attached to the previous lecture

you found this starting project

which is a standard react project,

which I did create with create react app.

Now I didn't really change the component code too much.

I just cleaned up the index JS file a little bit

and I did not delete the app test JS file,

which we did not use up to this point in the course,

and the setup test JS file

because we will need those files now.

Now set up tests JS, as the name implies,

just does some setup work

and we don't need to do anything else in this file.

But the app test JS file is quite interesting.

This is a file that contains some testing code

and it is there out of the box.

Later in this module

we will also write our own tests from scratch.

This is a file which is there to test this app component

because the convention is to name your testing files

like your component files,

just with the word test in the file name.

So dot test dot JS as an extension to be precise.

And in this app test JS file.

We have this test function

which we execute here, which takes two arguments.

The first argument is a description of the test.

This is up to you.

It helps you identify this test in the testing output

which we'll see in a couple of minutes.

And it's especially helpful

if you have an app with more than one test, of course.

The second argument is a function

an anonymous function, which is the point here

which contains the actual test and code.

So that's the code which will be executed

once we run our test.

And in there, we do a couple of things

which we don't fully understand yet

but we will soon understand it.

We rendered the app component in the end with help

of that render function imported from the testing library.

So from that third party package

then we get hold of some element on that virtual screen.

So to say, so in that simulated browser.

So to say, into which this app is rendered,

we get hold of some element in there

and we identify an element

by the text that is rendered inside of it.

Here we are looking for the text,

learn react in a case insensitive way.

This is our regular expression in case you're wondering.

And then we just check

if that element actually is in the document.

So if it exists in the document. And this test will fail

if this element is not found and it will succeed

if it is found.

And in app JS, we do have

this, content here

and we do have this

learn react text in this anchor tag.

And so if we look

for an element with a text of learn react case insensitive,

so casing does not matter, then this test should succeed

because such an element clearly exist here.

But that's all nice and theory.

How do we run this test?

For this, we got a script

just as we got a script for running the development server.

We run the development server.

So that we as a human can preview

our app and interact with it.

We run the automated tests to see if those work and for that

in packaged dot Json, we have this test script here

and we can run this test script from inside the terminal.

And here I'm using the terminal integrated

into visual studio code by running NPM test.

So just as NPM start, started the development server

NPM tests, will run our automated tests.

And here, if I now hit enter

this will start up the testing.

And actually, it does not run the tests right now.

Instead, we now have to press 8

to run all the tests it finds

and it will automatically look

for files that end with dot test dot JS

and then run all the tests that are defined

in there with that test function.

So in this case, this one test, which we have.

So if I now run, 8 here.

If I press 8, you see it executed my tests.

And then we get this test output here.

We see that it ran one test in total.

And that one test passed.

I'll come back to the difference between

tests suites, and tests.

A little bit later

here we see that it ran one test overall,

and that test passed.

And here we then see all the tests also,

all the tests that passed

in this case with the green check mark next to it.

And here we see that description text again

which we entered here.

So that is what helps us identify which test succeeded

or failed.

And for example, if I now go

to app JS here

and I remove this text, learn react

and I instead say, learn more.

You see if I save us the tests automatically rerun

because by default,

it watches your files and reruns the tests.

Whenever you save changes.

And now you see that we get a failed test here.

And if I scroll up, we get more information.

We see that this test failed

we see that by that red cross here.

And we also get an explanation of why it failed.

Unable to find an element with the text, learn react.

Then we get an output off the actual content

which had rendered where it tried to find that text

and where it failed to do so.

Of course, that is the content of app JS here.

Then we see the testing code

and the line that failed in this case get by text.

That's the line that failed.

And that is why desk test failed.

And now as a developer, we could either adjust our test.

If we want to have learned more here

or go back to learn react

to make sure that this test passes again.

And of course that's a rather dumb example.

It's just a basic example.

But that's the idea behind testing and how testing works.

Now, of course, we can always quit this testing mode

by hitting control C here

and then our files will not be watched anymore.

And we need to restart testing

with NPM test, if we want to do that.

So these are the basics.

Now let's dive a bit deeper.