Test-Driven Development (TDD) is a proven prevent bugs and improve the quality of your code - and it's fun! Learn the fundamentals of JavaScript testing in this beginner's tutorial. https://github.com/fireship-io/tdd-basics-project

#js #webdev #tutorial

🔗 Resources

Wallaby (20% discount) https://bit.ly/34KDnHP
Jest https://jestjs.io/
Cypress https://www.cypress.io/
Software Testing in 100 Seconds https://youtu.be/u6QfIXgjwGQ

📚 Chapters

00:00 Why Test?
01:13 Test-Driven Development (TDD) Philosophy
02:07 Functional Testing
03:40 Non-Functional Testing
03:53 JS Interview Question
04:12 Setting up Jest
06:04 Writing your First Test
09:05 Setup & Teardown
10:29 Code Coverage Report
10:57 Cypress E2E

 🤓 Install the quiz app

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

🔥 Watch more with Fireship PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T14:06:06.408Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
3c378676-8f6c-4bb5-a7ff-e4245381d5b0
1ae792d5c3aa1779685ec817183d34cbf4586f4df9d61cf8eb472a589336cc57
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Red, green, refactor.
Imagine you're sitting in a technical interview for an entry level web developer job and they ask you to implement a dynamic time warping algorithm to measure the similarity between 2 sequences in logarithmic time.
Instead of freaking out and wondering what this has to do with jQuery, you can just Say, no problem.
Let me write a few test cases for that first.
Not only will that buy you some time, but it also makes you look like you know what you're doing.
Test driven development is a technique where you describe behavior of your code before you go and implement it.
If you trust the science, testing will help reduce bugs and improve the maintainability of your code base in the long run.
And if you're new to programming, knowing how to test your code is one of the most powerful ways to level up as a developer.
Not only is it fun, but it will also teach you about your code in unexpected ways and and make you much better at debugging it.
Today's video will teach you everything you need to know to get started with software testing as a developer.
We'll talk about a bunch of different testing strategies from a high level, then take a a hands on approach by implementing unit tests from scratch with Jest.
And we'll also look at end to end testing with a tool called Cypress.
But most importantly, by the end of the video, you'll learn why testing is valuable and how to make the decision about whether or not you should test something, because it's a practice that walks a very fine line between being valuable and a complete waste of time.
Before we get started, make sure to hit the like button and subscribe.
In the last video, I explained how software testing works.
But if you missed it, automated testing is basically just a way to write code that describes to your requirements and validates your main application code.
Now, most developers I know, and myself included, generally don't start writing tests until we have a working feature, or maybe we just don't write any tests at all.
And that's especially true with front end development because UI requirements tend to change frequently.
But if you follow the principle of Test Driven Development, You'll write your test before you implement your actual code.
And a common mantra is red, green, refactor, which means you write a failing test first, red, then you write some code to get it passing, green, then you go back and optimize or refactor the code.
It's not always practical to do this, but if you have a project with very clear requirements, you might find that TDD actually improves your productivity.
Now, let's take a look at a bunch of different testing strategies and see how they add value to a code base.
At the lowest level, we dev unit testing, where the goal is to validate the behavior of individual functions, methods, or just units of code.
We'll get hands on with unit testing in just a minute.
The next level up is integration testing, which involves testing multiple units of code together.
For example, you might have a React component and a hook to fetch something from a database.
You can unit test each of these individually, but then have an integration test to see how well they work together.
Like, is the component actually able to Use the hook to get the data that it needs for the UI.
From there, we have end to end testing, which runs your app in a simulated environment and attempts to emulate actual user behavior.
There's a really awesome tool called Cypress that has a browser based test runner that allows you to program tests where users click on of buttons, fill out forms, then assert that the actual changes to the DOM or the UI are valid.
Personally, I find end to end tests to be the most valuable ones that I write.
So make sure to stay tuned until the end of this video to see Cypress in action.
In my opinion, these three testing strategies are the most important ones to know, but there are a lot of other terms that get thrown out there that you may wanna be familiar with.
Acceptance testing is a form of testing that makes sure that the software meets all of the client's requirements.
Stamp.
Then you have system testing to ensure that everything works on actual servers or hardware.
Then you have things like sanity or smoke test.
On a large application, you may have thousands of tests to run, and this can actually take a very long time and delay everybody else's work.
A smoke test runs a few of the most important tests burst to make sure the app isn't on fire before proceeding with the rest of the test suite.
Now at this point, we've only looked at functional testing, but there are also non functional tests support things like performance, usability, and security.
You'll often hear terms like stress testing or failover testing, which are used to test the capabilities of the infrastructure sure as opposed to the code itself.
Now that you know what all this fancy testing jargon means, let's get our hands dirty in JavaScript by pretending that we're in an actual technical interview.
We're required to implement a stack data structure where the last item in is the first item out.
It's very similar to an array, but we have to implement it without using a JavaScript array.
Now before we can start, we need to initialize a project and keep in mind that you can find the source code for this on GitHub.
I'm using Vite by running the npm init vitejs/app command, then selecting the vanilla JavaScript option, that gives us a simple project to get started in.
Then I'll add the Jest testing framework to it by running npm install jest, which itself will be looking for any files in your project that end in dot test dotjs.
Let's go ahead and create a test directory, then add a testing file to it.
To keep things simple, I'm going to implement our code and also test it in the stack dot test dotjs file.
Now to run the code in this file, we need to execute the Jest test runner.
We can do that by going to our package.
Json and setting up a new npm script called test that runs the Jest command.
In addition, I'll add the watch all command to have Jest watch our code in the background and rerun the test anytime it changes, and also the verbose flag to add some extra output to the terminal.
Go ahead and run npm test from the command line and you should get your first failing test because it's detecting that file, but we haven't actually written any code there yet.
One other optional, but highly recommended thing we can do here is add types to the project act to give us IntelliSense for all the matchers built into Jest, install the types using npm, then create a Jsconfig.
Json file that has a type position property for Jest.
This will allow Versus Code to provide IntelliSense for everything built into Jest, making your life way easier.
One other random pro tip I'll throw out there, is that you may also want to install the Wallaby plugin.
It's a paid Versus Code extension with a free trial, but it will tell you whether or not your tests are passing directly in the editor without having to look at the terminal and that can give you a really nice productivity boost.
I'm going to use the terminal in this video, but Wallaby is nice enough to provide us with a discount, so feel free to check that out in the description below.
And now we're ready to proceed with our interview.
The first thing I'll do is use the describe function engine to describe the thing it is that I'm testing, which in this case is the stack.
It takes a callback function as the second argument, inside of which we can define multiple individual tests by using the test function or it, both of which do the exact same thing.
We'll create a very simple test suite here with only 3 requirement, we'll wanna make sure that our stack is created empty, that it can push items to the top, and it can also pop or remove items from the top.
At this point, if we go ahead and save the file, we should get a failing test suite because we've only described our requirements and haven't actually implemented any testing code yet.
In some cases, you may want to hold off on the test implementation, in which case you can use the to do method to make the test pass while you figure things out.
Now let's go ahead and implement our first test.
The main goal of the first test is to ensure that our stack can be instantiated with a valid date, let's go ahead and instantiate a class that doesn't exist to represent the object that we want to test.
From there, we'll use expect to to write an expectation to make sure that our code does what is expected.
It should have a top property that represents the index of the item at the top of the pack.
Because it's empty when it's first created, the value should be negative 1.
2 b is a matcher that will test the actual value to the correct value.
Now, here's where test driven development starts to get really cool.
Go ahead and save the file and you'll notice that we get a failing test.
If we look at the output closely, date, it'll tell us exactly which line of code failed and why.
It says reference error, stack is not defined.
We can use that feedback as a starting point to start implementing our code.
To to address the error, we'll first need to define a class called stack.
Go ahead and define it, then save the file, then you'll notice that we still get a failing test, but this time it goes down to the expectation telling us that it expected negative one, but received undefined as the return value.
To address that issue, we need to add a constructor to the class to initialize it with the proper data.
Let's give it a top value of 0 and then we'll also define an item's property here to represent the stack itself as an empty object.
Because remember, we're not allowed to use arrays in this problem.
Go ahead and save the file, And now we finally get a passing test.
You can also add multiple expectations to a single test.
Let's go ahead and test the stack back items property to make sure that it's an empty object.
But when we do that, you'll notice that we now get a failing test, even though we're definitely comparing an empty object to an empty object.
And it's actually not an issue with our implementation, but an issue with the test itself.
The 2 b matcher checks for referentially quality between 2 objects.
In this case, both objects are empty, but they're 2 different objects in memory which is causing the test to fail.
What we need to do here is use a different matcher.
The to equal matcher would be a better choice because it checks for value equality instead of the object reference itself.
An important takeaway here is that it's not always your main application code that's the problem, it might be a bug in the test itself And unfortunately, we don't write tests for our tests.
Now let's move on to our second test to see if a stack can push an item to the top.
What What you'll notice is that the first thing I'm doing is initializing a new stack just like we did in the previous test, but there's actually a more efficient way to do this.
Jest has a set of helper functions for setup and teardown.
These are really useful because code duplication can get really bad inside of a test suite.
For example, we might set up a global variable for the stack, then use the before each hook to reinitialize it before each new test.
That'll give us an empty object to work work with before each test so we don't have to set it up manually in each one.
Now going into our second test, we'll call the push method with an item and then we'll expect the top value to be incremented by 1 and we'll add a peak property to get the top of the stack and we'll expect like that value to equal the value that we just pushed to it.
That'll give us a failing test and then we can once again go into our source code and start implementing the features needed to get to a passing test.
In general, what you'll wanna do here is try to get to a passing test as soon as possible.
Once you have that passing test, you can then go back and refactor and look for optimizations to make while trying to keep your test in the green.
There's just something very psychologically satisfying when you go from a red failing test to a green passing test.
My challenge to you is to now implement the final requirement in the test suite.
Try to use test driven development to implement a feature that can pop an item off of the stack.
Speaking of psychologically satisfying, another thing you can do is run a code coverage report, which will give you an idea of how well your tests cover your actual source code.
Back in the package JSON, add the coverage flag to the jest command, rerun it, then You'll get this report generated that tells you the percentage of code covered by your test suite.
That can be useful at times, but mostly it just gives you a full sense of security.
Geek.
100% code coverage doesn't mean that you have a good test suite, but it may be a good thing to show your product manager or client.
What I wanna show you next is a lot more fun and interesting and that is end to end testing.
Unlike a unit test, which is designed to be fast and simple, an end to end test is very long and complex and takes a while to run because it simulates actual user behaviors in the browser.
We could write our end to end test with Jest, utilizing that puppeteer package.
However, my favorite way to write end to end test is with a tool called Cypress.
Install it by running npm install Cypress, and this will take a few minutes speed because it's downloading an actual browser that will run your tests in a real world environment.
When the installation is complete, we can go into our package.
Json and add an end to end script that runs the Cypress open command.
That should open up the test runner which comes with a bunch of built in examples.
If You click on the actions example, you'll notice it starts running a test suite by filling out a form, clicking on buttons, and doing all kinds of other stuff.
When I use Cypress for my own projects, I use the Firebase Emulator to create a mock database and mock user authentication, which allows me to test my apps efficiently in an environment that is very similar to how they'll look in production.
Now, if we go back into our source code, you'll notice that a Cypress directory was created.
We can find that source mode for this example test by going to the integration folder, to the actions dot spec file.
And just like in Jest, We first define a test suite, then inside of it, we have multiple tests with the it keyword.
Now the cool thing about Cypress is that it makes it very easy to code these automated interactions with your website.
It has a Jquery like syntax that allows you to match a DOM element, like, say, a form input, then type into it with whatever text you provide.
You can then run expectations with should to ensure that it has the proper value, CSS style, or whatever else is important in the UI.
It's a really awesome tool and I'm not sponsored by them in any way.
But I'm gonna go ahead and wrap things up there.
If this video helped you, please like and subscribe, and consider becoming a pro member to get access to more advanced content.
Thanks watching and I will see you in the next one.

Speaker 0: Red, green, refactor. Imagine you're sitting in a technical interview for an entry level web developer job and they ask you to implement a dynamic time warping algorithm to measure the similarity between 2 sequences in logarithmic time. Instead of freaking out and wondering what this has to do with jQuery, you can just Say, no problem. Let me write a few test cases for that first. Not only will that buy you some time, but it also makes you look like you know what you're doing.

Test driven development is a technique where you describe behavior of your code before you go and implement it. If you trust the science, testing will help reduce bugs and improve the maintainability of your code base in the long run. And if you're new to programming, knowing how to test your code is one of the most powerful ways to level up as a developer. Not only is it fun, but it will also teach you about your code in unexpected ways and and make you much better at debugging it. Today's video will teach you everything you need to know to get started with software testing as a developer.

We'll talk about a bunch of different testing strategies from a high level, then take a a hands on approach by implementing unit tests from scratch with Jest. And we'll also look at end to end testing with a tool called Cypress. But most importantly, by the end of the video, you'll learn why testing is valuable and how to make the decision about whether or not you should test something, because it's a practice that walks a very fine line between being valuable and a complete waste of time. Before we get started, make sure to hit the like button and subscribe. In the last video, I explained how software testing works.

But if you missed it, automated testing is basically just a way to write code that describes to your requirements and validates your main application code. Now, most developers I know, and myself included, generally don't start writing tests until we have a working feature, or maybe we just don't write any tests at all. And that's especially true with front end development because UI requirements tend to change frequently. But if you follow the principle of Test Driven Development, You'll write your test before you implement your actual code. And a common mantra is red, green, refactor, which means you write a failing test first, red, then you write some code to get it passing, green, then you go back and optimize or refactor the code.

It's not always practical to do this, but if you have a project with very clear requirements, you might find that TDD actually improves your productivity. Now, let's take a look at a bunch of different testing strategies and see how they add value to a code base. At the lowest level, we dev unit testing, where the goal is to validate the behavior of individual functions, methods, or just units of code. We'll get hands on with unit testing in just a minute. The next level up is integration testing, which involves testing multiple units of code together.

For example, you might have a React component and a hook to fetch something from a database. You can unit test each of these individually, but then have an integration test to see how well they work together. Like, is the component actually able to Use the hook to get the data that it needs for the UI. From there, we have end to end testing, which runs your app in a simulated environment and attempts to emulate actual user behavior. There's a really awesome tool called Cypress that has a browser based test runner that allows you to program tests where users click on of buttons, fill out forms, then assert that the actual changes to the DOM or the UI are valid.

Personally, I find end to end tests to be the most valuable ones that I write. So make sure to stay tuned until the end of this video to see Cypress in action. In my opinion, these three testing strategies are the most important ones to know, but there are a lot of other terms that get thrown out there that you may wanna be familiar with. Acceptance testing is a form of testing that makes sure that the software meets all of the client's requirements. Stamp.

Then you have system testing to ensure that everything works on actual servers or hardware. Then you have things like sanity or smoke test. On a large application, you may have thousands of tests to run, and this can actually take a very long time and delay everybody else's work. A smoke test runs a few of the most important tests burst to make sure the app isn't on fire before proceeding with the rest of the test suite. Now at this point, we've only looked at functional testing, but there are also non functional tests support things like performance, usability, and security.

You'll often hear terms like stress testing or failover testing, which are used to test the capabilities of the infrastructure sure as opposed to the code itself. Now that you know what all this fancy testing jargon means, let's get our hands dirty in JavaScript by pretending that we're in an actual technical interview. We're required to implement a stack data structure where the last item in is the first item out. It's very similar to an array, but we have to implement it without using a JavaScript array. Now before we can start, we need to initialize a project and keep in mind that you can find the source code for this on GitHub.

I'm using Vite by running the npm init vitejs/app command, then selecting the vanilla JavaScript option, that gives us a simple project to get started in. Then I'll add the Jest testing framework to it by running npm install jest, which itself will be looking for any files in your project that end in dot test dotjs. Let's go ahead and create a test directory, then add a testing file to it. To keep things simple, I'm going to implement our code and also test it in the stack dot test dotjs file. Now to run the code in this file, we need to execute the Jest test runner.

We can do that by going to our package. Json and setting up a new npm script called test that runs the Jest command. In addition, I'll add the watch all command to have Jest watch our code in the background and rerun the test anytime it changes, and also the verbose flag to add some extra output to the terminal. Go ahead and run npm test from the command line and you should get your first failing test because it's detecting that file, but we haven't actually written any code there yet. One other optional, but highly recommended thing we can do here is add types to the project act to give us IntelliSense for all the matchers built into Jest, install the types using npm, then create a Jsconfig.

Json file that has a type position property for Jest. This will allow Versus Code to provide IntelliSense for everything built into Jest, making your life way easier. One other random pro tip I'll throw out there, is that you may also want to install the Wallaby plugin. It's a paid Versus Code extension with a free trial, but it will tell you whether or not your tests are passing directly in the editor without having to look at the terminal and that can give you a really nice productivity boost. I'm going to use the terminal in this video, but Wallaby is nice enough to provide us with a discount, so feel free to check that out in the description below.

And now we're ready to proceed with our interview. The first thing I'll do is use the describe function engine to describe the thing it is that I'm testing, which in this case is the stack. It takes a callback function as the second argument, inside of which we can define multiple individual tests by using the test function or it, both of which do the exact same thing. We'll create a very simple test suite here with only 3 requirement, we'll wanna make sure that our stack is created empty, that it can push items to the top, and it can also pop or remove items from the top. At this point, if we go ahead and save the file, we should get a failing test suite because we've only described our requirements and haven't actually implemented any testing code yet.

In some cases, you may want to hold off on the test implementation, in which case you can use the to do method to make the test pass while you figure things out. Now let's go ahead and implement our first test. The main goal of the first test is to ensure that our stack can be instantiated with a valid date, let's go ahead and instantiate a class that doesn't exist to represent the object that we want to test. From there, we'll use expect to to write an expectation to make sure that our code does what is expected. It should have a top property that represents the index of the item at the top of the pack.

Because it's empty when it's first created, the value should be negative 1. 2 b is a matcher that will test the actual value to the correct value. Now, here's where test driven development starts to get really cool. Go ahead and save the file and you'll notice that we get a failing test. If we look at the output closely, date, it'll tell us exactly which line of code failed and why.

It says reference error, stack is not defined. We can use that feedback as a starting point to start implementing our code. To to address the error, we'll first need to define a class called stack. Go ahead and define it, then save the file, then you'll notice that we still get a failing test, but this time it goes down to the expectation telling us that it expected negative one, but received undefined as the return value. To address that issue, we need to add a constructor to the class to initialize it with the proper data.

Let's give it a top value of 0 and then we'll also define an item's property here to represent the stack itself as an empty object. Because remember, we're not allowed to use arrays in this problem. Go ahead and save the file, And now we finally get a passing test. You can also add multiple expectations to a single test. Let's go ahead and test the stack back items property to make sure that it's an empty object.

But when we do that, you'll notice that we now get a failing test, even though we're definitely comparing an empty object to an empty object. And it's actually not an issue with our implementation, but an issue with the test itself. The 2 b matcher checks for referentially quality between 2 objects. In this case, both objects are empty, but they're 2 different objects in memory which is causing the test to fail. What we need to do here is use a different matcher.

The to equal matcher would be a better choice because it checks for value equality instead of the object reference itself. An important takeaway here is that it's not always your main application code that's the problem, it might be a bug in the test itself And unfortunately, we don't write tests for our tests. Now let's move on to our second test to see if a stack can push an item to the top. What What you'll notice is that the first thing I'm doing is initializing a new stack just like we did in the previous test, but there's actually a more efficient way to do this. Jest has a set of helper functions for setup and teardown.

These are really useful because code duplication can get really bad inside of a test suite. For example, we might set up a global variable for the stack, then use the before each hook to reinitialize it before each new test. That'll give us an empty object to work work with before each test so we don't have to set it up manually in each one. Now going into our second test, we'll call the push method with an item and then we'll expect the top value to be incremented by 1 and we'll add a peak property to get the top of the stack and we'll expect like that value to equal the value that we just pushed to it. That'll give us a failing test and then we can once again go into our source code and start implementing the features needed to get to a passing test.

In general, what you'll wanna do here is try to get to a passing test as soon as possible. Once you have that passing test, you can then go back and refactor and look for optimizations to make while trying to keep your test in the green. There's just something very psychologically satisfying when you go from a red failing test to a green passing test. My challenge to you is to now implement the final requirement in the test suite. Try to use test driven development to implement a feature that can pop an item off of the stack.

Speaking of psychologically satisfying, another thing you can do is run a code coverage report, which will give you an idea of how well your tests cover your actual source code. Back in the package JSON, add the coverage flag to the jest command, rerun it, then You'll get this report generated that tells you the percentage of code covered by your test suite. That can be useful at times, but mostly it just gives you a full sense of security. Geek. 100% code coverage doesn't mean that you have a good test suite, but it may be a good thing to show your product manager or client.

What I wanna show you next is a lot more fun and interesting and that is end to end testing. Unlike a unit test, which is designed to be fast and simple, an end to end test is very long and complex and takes a while to run because it simulates actual user behaviors in the browser. We could write our end to end test with Jest, utilizing that puppeteer package. However, my favorite way to write end to end test is with a tool called Cypress. Install it by running npm install Cypress, and this will take a few minutes speed because it's downloading an actual browser that will run your tests in a real world environment.

When the installation is complete, we can go into our package. Json and add an end to end script that runs the Cypress open command. That should open up the test runner which comes with a bunch of built in examples. If You click on the actions example, you'll notice it starts running a test suite by filling out a form, clicking on buttons, and doing all kinds of other stuff. When I use Cypress for my own projects, I use the Firebase Emulator to create a mock database and mock user authentication, which allows me to test my apps efficiently in an environment that is very similar to how they'll look in production.

Now, if we go back into our source code, you'll notice that a Cypress directory was created. We can find that source mode for this example test by going to the integration folder, to the actions dot spec file. And just like in Jest, We first define a test suite, then inside of it, we have multiple tests with the it keyword. Now the cool thing about Cypress is that it makes it very easy to code these automated interactions with your website. It has a Jquery like syntax that allows you to match a DOM element, like, say, a form input, then type into it with whatever text you provide.

You can then run expectations with should to ensure that it has the proper value, CSS style, or whatever else is important in the UI. It's a really awesome tool and I'm not sponsored by them in any way. But I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe, and consider becoming a pro member to get access to more advanced content. Thanks watching and I will see you in the next one.
Red, green, refactor. Imagine you're sitting in a technical interview for an entry level web developer job and they ask you to implement a dynamic time warping algorithm to measure the similarity between 2 sequences in logarithmic time. Instead of freaking out and wondering what this has to do with jQuery, you can just Say, no problem. Let me write a few test cases for that first.
Not only will that buy you some time, but it also makes you look like you know what you're doing. Test driven development is a technique where you describe behavior of your code before you go and implement it. If you trust the science, testing will help reduce bugs and improve the maintainability of your code base in the long run. And if you're new to programming, knowing how to test your code is one of the most powerful ways to level up as a developer. Not only is it fun, but it will also teach you about your code in unexpected ways and and make you much better at debugging it. Today's video will teach you everything you need to know to get started with software testing as a developer. We'll talk about a bunch of different testing strategies from a high level, then take a a hands on approach by implementing unit tests from scratch with Jest. And we'll also look at end to end testing with a tool called Cypress.
software development
software
programming
video gaming
But most importantly, by the end of the video, you'll learn why testing is valuable and how to make the decision about whether or not you should test something, because it's a practice that walks a very fine line between being valuable and a complete waste of time.
Before we get started, make sure to hit the like button and subscribe. In the last video, I explained how software testing works. But if you missed it, automated testing is basically just a way to write code that describes to your requirements and validates your main application code. Now, most developers I know, and myself included, generally don't start writing tests until we have a working feature, or maybe we just don't write any tests at all. And that's especially true with front end development because UI requirements tend to change frequently. But if you follow the principle of Test Driven Development, You'll write your test before you implement your actual code.
software development
software
And a common mantra is red, green, refactor, which means you write a failing test first, red, then you write some code to get it passing, green, then you go back and optimize or refactor the code. It's not always practical to do this, but if you have a project with very clear requirements, you might find that TDD actually improves your productivity. Now, let's take a look at a bunch of different testing strategies and see how they add value to a code base. At the lowest level, we dev unit testing, where the goal is to validate the behavior of individual functions, methods, or just units of code.
We'll get hands on with unit testing in just a minute. The next level up is integration testing, which involves testing multiple units of code together. For example, you might have a React component and a hook to fetch something from a database. You can unit test each of these individually, but then have an integration test to see how well they work together. Like, is the component actually able to Use the hook to get the data that it needs for the UI. From there, we have end to end testing, which runs your app in a simulated environment and attempts to emulate actual user behavior. There's a really awesome tool called Cypress that has a browser based test runner that allows you to program tests where users click on of buttons, fill out forms, then assert that the actual changes to the DOM or the UI are valid.
databases
data
programming
Personally, I find end to end tests to be the most valuable ones that I write. So make sure to stay tuned until the end of this video to see Cypress in action.
In my opinion, these three testing strategies are the most important ones to know, but there are a lot of other terms that get thrown out there that you may wanna be familiar with. Acceptance testing is a form of testing that makes sure that the software meets all of the client's requirements. Stamp. Then you have system testing to ensure that everything works on actual servers or hardware. Then you have things like sanity or smoke test. On a large application, you may have thousands of tests to run, and this can actually take a very long time and delay everybody else's work.
quality assurance
software development
software
A smoke test runs a few of the most important tests burst to make sure the app isn't on fire before proceeding with the rest of the test suite. Now at this point, we've only looked at functional testing, but there are also non functional tests support things like performance, usability, and security.
tobacco
You'll often hear terms like stress testing or failover testing, which are used to test the capabilities of the infrastructure sure as opposed to the code itself. Now that you know what all this fancy testing jargon means, let's get our hands dirty in JavaScript by pretending that we're in an actual technical interview. We're required to implement a stack data structure where the last item in is the first item out. It's very similar to an array, but we have to implement it without using a JavaScript array.
Now before we can start, we need to initialize a project and keep in mind that you can find the source code for this on GitHub. I'm using Vite by running the npm init vitejs/app command, then selecting the vanilla JavaScript option, that gives us a simple project to get started in.
software development
Then I'll add the Jest testing framework to it by running npm install jest, which itself will be looking for any files in your project that end in dot test dotjs. Let's go ahead and create a test directory, then add a testing file to it. To keep things simple, I'm going to implement our code and also test it in the stack dot test dotjs file. Now to run the code in this file, we need to execute the Jest test runner. We can do that by going to our package. Json and setting up a new npm script called test that runs the Jest command. In addition, I'll add the watch all command to have Jest watch our code in the background and rerun the test anytime it changes, and also the verbose flag to add some extra output to the terminal. Go ahead and run npm test from the command line and you should get your first failing test because it's detecting that file, but we haven't actually written any code there yet. One other optional, but highly recommended thing we can do here is add types to the project act to give us IntelliSense for all the matchers built into Jest, install the types using npm, then create a Jsconfig. Json file that has a type position property for Jest. This will allow Versus Code to provide IntelliSense for everything built into Jest, making your life way easier. One other random pro tip I'll throw out there, is that you may also want to install the Wallaby plugin. It's a paid Versus Code extension with a free trial, but it will tell you whether or not your tests are passing directly in the editor without having to look at the terminal and that can give you a really nice productivity boost. I'm going to use the terminal in this video, but Wallaby is nice enough to provide us with a discount, so feel free to check that out in the description below.
And now we're ready to proceed with our interview. The first thing I'll do is use the describe function engine to describe the thing it is that I'm testing, which in this case is the stack. It takes a callback function as the second argument, inside of which we can define multiple individual tests by using the test function or it, both of which do the exact same thing. We'll create a very simple test suite here with only 3 requirement, we'll wanna make sure that our stack is created empty, that it can push items to the top, and it can also pop or remove items from the top.
programming
operations
At this point, if we go ahead and save the file, we should get a failing test suite because we've only described our requirements and haven't actually implemented any testing code yet. In some cases, you may want to hold off on the test implementation, in which case you can use the to do method to make the test pass while you figure things out. Now let's go ahead and implement our first test. The main goal of the first test is to ensure that our stack can be instantiated with a valid date, let's go ahead and instantiate a class that doesn't exist to represent the object that we want to test. From there, we'll use expect to to write an expectation to make sure that our code does what is expected. It should have a top property that represents the index of the item at the top of the pack. Because it's empty when it's first created, the value should be negative 1. 2 b is a matcher that will test the actual value to the correct value. Now, here's where test driven development starts to get really cool. Go ahead and save the file and you'll notice that we get a failing test.
If we look at the output closely, date, it'll tell us exactly which line of code failed and why. It says reference error, stack is not defined. We can use that feedback as a starting point to start implementing our code. To to address the error, we'll first need to define a class called stack. Go ahead and define it, then save the file, then you'll notice that we still get a failing test, but this time it goes down to the expectation telling us that it expected negative one, but received undefined as the return value.
programming
To address that issue, we need to add a constructor to the class to initialize it with the proper data. Let's give it a top value of 0 and then we'll also define an item's property here to represent the stack itself as an empty object. Because remember, we're not allowed to use arrays in this problem. Go ahead and save the file, And now we finally get a passing test. You can also add multiple expectations to a single test. Let's go ahead and test the stack back items property to make sure that it's an empty object. But when we do that, you'll notice that we now get a failing test, even though we're definitely comparing an empty object to an empty object. And it's actually not an issue with our implementation, but an issue with the test itself. The 2 b matcher checks for referentially quality between 2 objects.
In this case, both objects are empty, but they're 2 different objects in memory which is causing the test to fail. What we need to do here is use a different matcher. The to equal matcher would be a better choice because it checks for value equality instead of the object reference itself. An important takeaway here is that it's not always your main application code that's the problem, it might be a bug in the test itself And unfortunately, we don't write tests for our tests.
logic
Now let's move on to our second test to see if a stack can push an item to the top. What What you'll notice is that the first thing I'm doing is initializing a new stack just like we did in the previous test, but there's actually a more efficient way to do this. Jest has a set of helper functions for setup and teardown. These are really useful because code duplication can get really bad inside of a test suite. For example, we might set up a global variable for the stack, then use the before each hook to reinitialize it before each new test. That'll give us an empty object to work work with before each test so we don't have to set it up manually in each one. Now going into our second test, we'll call the push method with an item and then we'll expect the top value to be incremented by 1 and we'll add a peak property to get the top of the stack and we'll expect like that value to equal the value that we just pushed to it. That'll give us a failing test and then we can once again go into our source code and start implementing the features needed to get to a passing test. In general, what you'll wanna do here is try to get to a passing test as soon as possible. Once you have that passing test, you can then go back and refactor and look for optimizations to make while trying to keep your test in the green. There's just something very psychologically satisfying when you go from a red failing test to a green passing test. My challenge to you is to now implement the final requirement in the test suite.
Try to use test driven development to implement a feature that can pop an item off of the stack. Speaking of psychologically satisfying, another thing you can do is run a code coverage report, which will give you an idea of how well your tests cover your actual source code.
software development
programming
software
Back in the package JSON, add the coverage flag to the jest command, rerun it, then You'll get this report generated that tells you the percentage of code covered by your test suite.
That can be useful at times, but mostly it just gives you a full sense of security. Geek. 100% code coverage doesn't mean that you have a good test suite, but it may be a good thing to show your product manager or client. What I wanna show you next is a lot more fun and interesting and that is end to end testing.
security
quality assurance
Unlike a unit test, which is designed to be fast and simple, an end to end test is very long and complex and takes a while to run because it simulates actual user behaviors in the browser. We could write our end to end test with Jest, utilizing that puppeteer package. However, my favorite way to write end to end test is with a tool called Cypress. Install it by running npm install Cypress, and this will take a few minutes speed because it's downloading an actual browser that will run your tests in a real world environment. When the installation is complete, we can go into our package. Json and add an end to end script that runs the Cypress open command. That should open up the test runner which comes with a bunch of built in examples. If You click on the actions example, you'll notice it starts running a test suite by filling out a form, clicking on buttons, and doing all kinds of other stuff. When I use Cypress for my own projects, I use the Firebase Emulator to create a mock database and mock user authentication, which allows me to test my apps efficiently in an environment that is very similar to how they'll look in production. Now, if we go back into our source code, you'll notice that a Cypress directory was created. We can find that source mode for this example test by going to the integration folder, to the actions dot spec file. And just like in Jest, We first define a test suite, then inside of it, we have multiple tests with the it keyword. Now the cool thing about Cypress is that it makes it very easy to code these automated interactions with your website. It has a Jquery like syntax that allows you to match a DOM element, like, say, a form input, then type into it with whatever text you provide.
You can then run expectations with should to ensure that it has the proper value, CSS style, or whatever else is important in the UI. It's a really awesome tool and I'm not sponsored by them in any way. But I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe, and consider becoming a pro member to get access to more advanced content. Thanks watching and I will see you in the next one.
youtube
social media
multimedia
video gaming
documentary
Red, green, refactor. Imagine you're sitting in a technical interview for an entry level web developer job and they ask you to implement a dynamic time warping algorithm to measure the similarity between 2 sequences in logarithmic time. Instead of freaking out and wondering what this has to do with jQuery, you can just Say, no problem. Let me write a few test cases for that first. Not only will that buy you some time, but it also makes you look like you know what you're doing. Test driven development is a technique where you describe behavior of your code before you go and implement it. If you trust the science, testing will help reduce bugs and improve the maintainability of your code base in the long run. And if you're new to programming, knowing how to test your code is one of the most powerful ways to level up as a developer. Not only is it fun, but it will also teach you about your code in unexpected ways and and make you much better at debugging it. Today's video will teach you everything you need to know to get started with software testing as a developer. We'll talk about a bunch of different testing strategies from a high level, then take a a hands on approach by implementing unit tests from scratch with Jest. And we'll also look at end to end testing with a tool called Cypress. But most importantly, by the end of the video, you'll learn why testing is valuable and how to make the decision about whether or not you should test something, because it's a practice that walks a very fine line between being valuable and a complete waste of time. Before we get started, make sure to hit the like button and subscribe. In the last video, I explained how software testing works. But if you missed it, automated testing is basically just a way to write code that describes to your requirements and validates your main application code. Now, most developers I know, and myself included, generally don't start writing tests until we have a working feature, or maybe we just don't write any tests at all. And that's especially true with front end development because UI requirements tend to change frequently. But if you follow the principle of Test Driven Development, You'll write your test before you implement your actual code. And a common mantra is red, green, refactor, which means you write a failing test first, red, then you write some code to get it passing, green, then you go back and optimize or refactor the code. It's not always practical to do this, but if you have a project with very clear requirements, you might find that TDD actually improves your productivity. Now, let's take a look at a bunch of different testing strategies and see how they add value to a code base. At the lowest level, we dev unit testing, where the goal is to validate the behavior of individual functions, methods, or just units of code. We'll get hands on with unit testing in just a minute. The next level up is integration testing, which involves testing multiple units of code together. For example, you might have a React component and a hook to fetch something from a database. You can unit test each of these individually, but then have an integration test to see how well they work together. Like, is the component actually able to Use the hook to get the data that it needs for the UI. From there, we have end to end testing, which runs your app in a simulated environment and attempts to emulate actual user behavior. There's a really awesome tool called Cypress that has a browser based test runner that allows you to program tests where users click on of buttons, fill out forms, then assert that the actual changes to the DOM or the UI are valid. Personally, I find end to end tests to be the most valuable ones that I write. So make sure to stay tuned until the end of this video to see Cypress in action. In my opinion, these three testing strategies are the most important ones to know, but there are a lot of other terms that get thrown out there that you may wanna be familiar with. Acceptance testing is a form of testing that makes sure that the software meets all of the client's requirements. Stamp. Then you have system testing to ensure that everything works on actual servers or hardware. Then you have things like sanity or smoke test. On a large application, you may have thousands of tests to run, and this can actually take a very long time and delay everybody else's work. A smoke test runs a few of the most important tests burst to make sure the app isn't on fire before proceeding with the rest of the test suite. Now at this point, we've only looked at functional testing, but there are also non functional tests support things like performance, usability, and security. You'll often hear terms like stress testing or failover testing, which are used to test the capabilities of the infrastructure sure as opposed to the code itself. Now that you know what all this fancy testing jargon means, let's get our hands dirty in JavaScript by pretending that we're in an actual technical interview. We're required to implement a stack data structure where the last item in is the first item out. It's very similar to an array, but we have to implement it without using a JavaScript array. Now before we can start, we need to initialize a project and keep in mind that you can find the source code for this on GitHub. I'm using Vite by running the npm init vitejs/app command, then selecting the vanilla JavaScript option, that gives us a simple project to get started in. Then I'll add the Jest testing framework to it by running npm install jest, which itself will be looking for any files in your project that end in dot test dotjs. Let's go ahead and create a test directory, then add a testing file to it. To keep things simple, I'm going to implement our code and also test it in the stack dot test dotjs file. Now to run the code in this file, we need to execute the Jest test runner. We can do that by going to our package. Json and setting up a new npm script called test that runs the Jest command. In addition, I'll add the watch all command to have Jest watch our code in the background and rerun the test anytime it changes, and also the verbose flag to add some extra output to the terminal. Go ahead and run npm test from the command line and you should get your first failing test because it's detecting that file, but we haven't actually written any code there yet. One other optional, but highly recommended thing we can do here is add types to the project act to give us IntelliSense for all the matchers built into Jest, install the types using npm, then create a Jsconfig. Json file that has a type position property for Jest. This will allow Versus Code to provide IntelliSense for everything built into Jest, making your life way easier. One other random pro tip I'll throw out there, is that you may also want to install the Wallaby plugin. It's a paid Versus Code extension with a free trial, but it will tell you whether or not your tests are passing directly in the editor without having to look at the terminal and that can give you a really nice productivity boost. I'm going to use the terminal in this video, but Wallaby is nice enough to provide us with a discount, so feel free to check that out in the description below. And now we're ready to proceed with our interview. The first thing I'll do is use the describe function engine to describe the thing it is that I'm testing, which in this case is the stack. It takes a callback function as the second argument, inside of which we can define multiple individual tests by using the test function or it, both of which do the exact same thing. We'll create a very simple test suite here with only 3 requirement, we'll wanna make sure that our stack is created empty, that it can push items to the top, and it can also pop or remove items from the top. At this point, if we go ahead and save the file, we should get a failing test suite because we've only described our requirements and haven't actually implemented any testing code yet. In some cases, you may want to hold off on the test implementation, in which case you can use the to do method to make the test pass while you figure things out. Now let's go ahead and implement our first test. The main goal of the first test is to ensure that our stack can be instantiated with a valid date, let's go ahead and instantiate a class that doesn't exist to represent the object that we want to test. From there, we'll use expect to to write an expectation to make sure that our code does what is expected. It should have a top property that represents the index of the item at the top of the pack. Because it's empty when it's first created, the value should be negative 1. 2 b is a matcher that will test the actual value to the correct value. Now, here's where test driven development starts to get really cool. Go ahead and save the file and you'll notice that we get a failing test. If we look at the output closely, date, it'll tell us exactly which line of code failed and why. It says reference error, stack is not defined. We can use that feedback as a starting point to start implementing our code. To to address the error, we'll first need to define a class called stack. Go ahead and define it, then save the file, then you'll notice that we still get a failing test, but this time it goes down to the expectation telling us that it expected negative one, but received undefined as the return value. To address that issue, we need to add a constructor to the class to initialize it with the proper data. Let's give it a top value of 0 and then we'll also define an item's property here to represent the stack itself as an empty object. Because remember, we're not allowed to use arrays in this problem. Go ahead and save the file, And now we finally get a passing test. You can also add multiple expectations to a single test. Let's go ahead and test the stack back items property to make sure that it's an empty object. But when we do that, you'll notice that we now get a failing test, even though we're definitely comparing an empty object to an empty object. And it's actually not an issue with our implementation, but an issue with the test itself. The 2 b matcher checks for referentially quality between 2 objects. In this case, both objects are empty, but they're 2 different objects in memory which is causing the test to fail. What we need to do here is use a different matcher. The to equal matcher would be a better choice because it checks for value equality instead of the object reference itself. An important takeaway here is that it's not always your main application code that's the problem, it might be a bug in the test itself And unfortunately, we don't write tests for our tests. Now let's move on to our second test to see if a stack can push an item to the top. What What you'll notice is that the first thing I'm doing is initializing a new stack just like we did in the previous test, but there's actually a more efficient way to do this. Jest has a set of helper functions for setup and teardown. These are really useful because code duplication can get really bad inside of a test suite. For example, we might set up a global variable for the stack, then use the before each hook to reinitialize it before each new test. That'll give us an empty object to work work with before each test so we don't have to set it up manually in each one. Now going into our second test, we'll call the push method with an item and then we'll expect the top value to be incremented by 1 and we'll add a peak property to get the top of the stack and we'll expect like that value to equal the value that we just pushed to it. That'll give us a failing test and then we can once again go into our source code and start implementing the features needed to get to a passing test. In general, what you'll wanna do here is try to get to a passing test as soon as possible. Once you have that passing test, you can then go back and refactor and look for optimizations to make while trying to keep your test in the green. There's just something very psychologically satisfying when you go from a red failing test to a green passing test. My challenge to you is to now implement the final requirement in the test suite. Try to use test driven development to implement a feature that can pop an item off of the stack. Speaking of psychologically satisfying, another thing you can do is run a code coverage report, which will give you an idea of how well your tests cover your actual source code. Back in the package JSON, add the coverage flag to the jest command, rerun it, then You'll get this report generated that tells you the percentage of code covered by your test suite. That can be useful at times, but mostly it just gives you a full sense of security. Geek. 100% code coverage doesn't mean that you have a good test suite, but it may be a good thing to show your product manager or client. What I wanna show you next is a lot more fun and interesting and that is end to end testing. Unlike a unit test, which is designed to be fast and simple, an end to end test is very long and complex and takes a while to run because it simulates actual user behaviors in the browser. We could write our end to end test with Jest, utilizing that puppeteer package. However, my favorite way to write end to end test is with a tool called Cypress. Install it by running npm install Cypress, and this will take a few minutes speed because it's downloading an actual browser that will run your tests in a real world environment. When the installation is complete, we can go into our package. Json and add an end to end script that runs the Cypress open command. That should open up the test runner which comes with a bunch of built in examples. If You click on the actions example, you'll notice it starts running a test suite by filling out a form, clicking on buttons, and doing all kinds of other stuff. When I use Cypress for my own projects, I use the Firebase Emulator to create a mock database and mock user authentication, which allows me to test my apps efficiently in an environment that is very similar to how they'll look in production. Now, if we go back into our source code, you'll notice that a Cypress directory was created. We can find that source mode for this example test by going to the integration folder, to the actions dot spec file. And just like in Jest, We first define a test suite, then inside of it, we have multiple tests with the it keyword. Now the cool thing about Cypress is that it makes it very easy to code these automated interactions with your website. It has a Jquery like syntax that allows you to match a DOM element, like, say, a form input, then type into it with whatever text you provide. You can then run expectations with should to ensure that it has the proper value, CSS style, or whatever else is important in the UI. It's a really awesome tool and I'm not sponsored by them in any way. But I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe, and consider becoming a pro member to get access to more advanced content. Thanks watching and I will see you in the next one.
Red,
red
green,
green
refactor.
refactor
Imagine
imagine
you're
you're
sitting
sitting
in
in
a
a
technical
technical
interview
interview
for
for
an
an
entry
entry
level
level
web
web
developer
developer
job
job
and
and
they
they
ask
ask
you
you
to
to
implement
implement
a
a
dynamic
dynamic
time
time
warping
warping
algorithm
algorithm
to
to
measure
measure
the
the
similarity
similarity
between
between
2
2
sequences
sequences
in
in
logarithmic
logarithmic
time.
time
Instead
instead
of
of
freaking
freaking
out
out
and
and
wondering
wondering
what
what
this
this
has
has
to
to
do
do
with
with
jQuery,
jquery
you
you
can
can
just
just
Say,
say
no
no
problem.
problem
Let
let
me
me
write
write
a
a
few
few
test
test
cases
cases
for
for
that
that
first.
first
Not
not
only
only
will
will
that
that
buy
buy
you
you
some
some
time,
time
but
but
it
it
also
also
makes
makes
you
you
look
look
like
like
you
you
know
know
what
what
you're
you're
doing.
doing
Test
test
driven
driven
development
development
is
is
a
a
technique
technique
where
where
you
you
describe
describe
behavior
behavior
of
of
your
your
code
code
before
before
you
you
go
go
and
and
implement
implement
it.
it
If
if
you
you
trust
trust
the
the
science,
science
testing
testing
will
will
help
help
reduce
reduce
bugs
bugs
and
and
improve
improve
the
the
maintainability
maintainability
of
of
your
your
code
code
base
base
in
in
the
the
long
long
run.
run
And
and
if
if
you're
you're
new
new
to
to
programming,
programming
knowing
knowing
how
how
to
to
test
test
your
your
code
code
is
is
one
one
of
of
the
the
most
most
powerful
powerful
ways
ways
to
to
level
level
up
up
as
as
a
a
developer.
developer
Not
not
only
only
is
is
it
it
fun,
fun
but
but
it
it
will
will
also
also
teach
teach
you
you
about
about
your
your
code
code
in
in
unexpected
unexpected
ways
ways
and
and
and
and
make
make
you
you
much
much
better
better
at
at
debugging
debugging
it.
it
Today's
today's
video
video
will
will
teach
teach
you
you
everything
everything
you
you
need
need
to
to
know
know
to
to
get
get
started
started
with
with
software
software
testing
testing
as
as
a
a
developer.
developer
We'll
we'll
talk
talk
about
about
a
a
bunch
bunch
of
of
different
different
testing
testing
strategies
strategies
from
from
a
a
high
high
level,
level
then
then
take
take
a
a
a
a
hands
hands
on
on
approach
approach
by
by
implementing
implementing
unit
unit
tests
tests
from
from
scratch
scratch
with
with
Jest.
jest
And
and
we'll
we'll
also
also
look
look
at
at
end
end
to
to
end
end
testing
testing
with
with
a
a
tool
tool
called
called
Cypress.
cypress
But
but
most
most
importantly,
importantly
by
by
the
the
end
end
of
of
the
the
video,
video
you'll
you'll
learn
learn
why
why
testing
testing
is
is
valuable
valuable
and
and
how
how
to
to
make
make
the
the
decision
decision
about
about
whether
whether
or
or
not
not
you
you
should
should
test
test
something,
something
because
because
it's
it's
a
a
practice
practice
that
that
walks
walks
a
a
very
very
fine
fine
line
line
between
between
being
being
valuable
valuable
and
and
a
a
complete
complete
waste
waste
of
of
time.
time
Before
before
we
we
get
get
started,
started
make
make
sure
sure
to
to
hit
hit
the
the
like
like
button
button
and
and
subscribe.
subscribe
In
in
the
the
last
last
video,
video
I
i
explained
explained
how
how
software
software
testing
testing
works.
works
But
but
if
if
you
you
missed
missed
it,
it
automated
automated
testing
testing
is
is
basically
basically
just
just
a
a
way
way
to
to
write
write
code
code
that
that
describes
describes
to
to
your
your
requirements
requirements
and
and
validates
validates
your
your
main
main
application
application
code.
code
Now,
now
most
most
developers
developers
I
i
know,
know
and
and
myself
myself
included,
included
generally
generally
don't
don't
start
start
writing
writing
tests
tests
until
until
we
we
have
have
a
a
working
working
feature,
feature
or
or
maybe
maybe
we
we
just
just
don't
don't
write
write
any
any
tests
tests
at
at
all.
all
And
and
that's
that's
especially
especially
true
true
with
with
front
front
end
end
development
development
because
because
UI
ui
requirements
requirements
tend
tend
to
to
change
change
frequently.
frequently
But
but
if
if
you
you
follow
follow
the
the
principle
principle
of
of
Test
test
Driven
driven
Development,
development
You'll
you'll
write
write
your
your
test
test
before
before
you
you
implement
implement
your
your
actual
actual
code.
code
And
and
a
a
common
common
mantra
mantra
is
is
red,
red
green,
green
refactor,
refactor
which
which
means
means
you
you
write
write
a
a
failing
failing
test
test
first,
first
red,
red
then
then
you
you
write
write
some
some
code
code
to
to
get
get
it
it
passing,
passing
green,
green
then
then
you
you
go
go
back
back
and
and
optimize
optimize
or
or
refactor
refactor
the
the
code.
code
It's
it's
not
not
always
always
practical
practical
to
to
do
do
this,
this
but
but
if
if
you
you
have
have
a
a
project
project
with
with
very
very
clear
clear
requirements,
requirements
you
you
might
might
find
find
that
that
TDD
tdd
actually
actually
improves
improves
your
your
productivity.
productivity
Now,
now
let's
let's
take
take
a
a
look
look
at
at
a
a
bunch
bunch
of
of
different
different
testing
testing
strategies
strategies
and
and
see
see
how
how
they
they
add
add
value
value
to
to
a
a
code
code
base.
base
At
at
the
the
lowest
lowest
level,
level
we
we
dev
dev
unit
unit
testing,
testing
where
where
the
the
goal
goal
is
is
to
to
validate
validate
the
the
behavior
behavior
of
of
individual
individual
functions,
functions
methods,
methods
or
or
just
just
units
units
of
of
code.
code
We'll
we'll
get
get
hands
hands
on
on
with
with
unit
unit
testing
testing
in
in
just
just
a
a
minute.
minute
The
the
next
next
level
level
up
up
is
is
integration
integration
testing,
testing
which
which
involves
involves
testing
testing
multiple
multiple
units
units
of
of
code
code
together.
together
For
for
example,
example
you
you
might
might
have
have
a
a
React
react
component
component
and
and
a
a
hook
hook
to
to
fetch
fetch
something
something
from
from
a
a
database.
database
You
you
can
can
unit
unit
test
test
each
each
of
of
these
these
individually,
individually
but
but
then
then
have
have
an
an
integration
integration
test
test
to
to
see
see
how
how
well
well
they
they
work
work
together.
together
Like,
like
is
is
the
the
component
component
actually
actually
able
able
to
to
Use
use
the
the
hook
hook
to
to
get
get
the
the
data
data
that
that
it
it
needs
needs
for
for
the
the
UI.
ui
From
from
there,
there
we
we
have
have
end
end
to
to
end
end
testing,
testing
which
which
runs
runs
your
your
app
app
in
in
a
a
simulated
simulated
environment
environment
and
and
attempts
attempts
to
to
emulate
emulate
actual
actual
user
user
behavior.
behavior
There's
there's
a
a
really
really
awesome
awesome
tool
tool
called
called
Cypress
cypress
that
that
has
has
a
a
browser
browser
based
based
test
test
runner
runner
that
that
allows
allows
you
you
to
to
program
program
tests
tests
where
where
users
users
click
click
on
on
of
of
buttons,
buttons
fill
fill
out
out
forms,
forms
then
then
assert
assert
that
that
the
the
actual
actual
changes
changes
to
to
the
the
DOM
dom
or
or
the
the
UI
ui
are
are
valid.
valid
Personally,
personally
I
i
find
find
end
end
to
to
end
end
tests
tests
to
to
be
be
the
the
most
most
valuable
valuable
ones
ones
that
that
I
i
write.
write
So
so
make
make
sure
sure
to
to
stay
stay
tuned
tuned
until
until
the
the
end
end
of
of
this
this
video
video
to
to
see
see
Cypress
cypress
in
in
action.
action
In
in
my
my
opinion,
opinion
these
these
three
three
testing
testing
strategies
strategies
are
are
the
the
most
most
important
important
ones
ones
to
to
know,
know
but
but
there
there
are
are
a
a
lot
lot
of
of
other
other
terms
terms
that
that
get
get
thrown
thrown
out
out
there
there
that
that
you
you
may
may
wanna
wanna
be
be
familiar
familiar
with.
with
Acceptance
acceptance
testing
testing
is
is
a
a
form
form
of
of
testing
testing
that
that
makes
makes
sure
sure
that
that
the
the
software
software
meets
meets
all
all
of
of
the
the
client's
client's
requirements.
requirements
Stamp.
stamp
Then
then
you
you
have
have
system
system
testing
testing
to
to
ensure
ensure
that
that
everything
everything
works
works
on
on
actual
actual
servers
servers
or
or
hardware.
hardware
Then
then
you
you
have
have
things
things
like
like
sanity
sanity
or
or
smoke
smoke
test.
test
On
on
a
a
large
large
application,
application
you
you
may
may
have
have
thousands
thousands
of
of
tests
tests
to
to
run,
run
and
and
this
this
can
can
actually
actually
take
take
a
a
very
very
long
long
time
time
and
and
delay
delay
everybody
everybody
else's
else's
work.
work
A
a
smoke
smoke
test
test
runs
runs
a
a
few
few
of
of
the
the
most
most
important
important
tests
tests
burst
burst
to
to
make
make
sure
sure
the
the
app
app
isn't
isn't
on
on
fire
fire
before
before
proceeding
proceeding
with
with
the
the
rest
rest
of
of
the
the
test
test
suite.
suite
Now
now
at
at
this
this
point,
point
we've
we've
only
only
looked
looked
at
at
functional
functional
testing,
testing
but
but
there
there
are
are
also
also
non
non
functional
functional
tests
tests
support
support
things
things
like
like
performance,
performance
usability,
usability
and
and
security.
security
You'll
you'll
often
often
hear
hear
terms
terms
like
like
stress
stress
testing
testing
or
or
failover
failover
testing,
testing
which
which
are
are
used
used
to
to
test
test
the
the
capabilities
capabilities
of
of
the
the
infrastructure
infrastructure
sure
sure
as
as
opposed
opposed
to
to
the
the
code
code
itself.
itself
Now
now
that
that
you
you
know
know
what
what
all
all
this
this
fancy
fancy
testing
testing
jargon
jargon
means,
means
let's
let's
get
get
our
our
hands
hands
dirty
dirty
in
in
JavaScript
javascript
by
by
pretending
pretending
that
that
we're
we're
in
in
an
an
actual
actual
technical
technical
interview.
interview
We're
we're
required
required
to
to
implement
implement
a
a
stack
stack
data
data
structure
structure
where
where
the
the
last
last
item
item
in
in
is
is
the
the
first
first
item
item
out.
out
It's
it's
very
very
similar
similar
to
to
an
an
array,
array
but
but
we
we
have
have
to
to
implement
implement
it
it
without
without
using
using
a
a
JavaScript
javascript
array.
array
Now
now
before
before
we
we
can
can
start,
start
we
we
need
need
to
to
initialize
initialize
a
a
project
project
and
and
keep
keep
in
in
mind
mind
that
that
you
you
can
can
find
find
the
the
source
source
code
code
for
for
this
this
on
on
GitHub.
github
I'm
i'm
using
using
Vite
vite
by
by
running
running
the
the
npm
npm
init
init
vitejs/app
vitejs/app
command,
command
then
then
selecting
selecting
the
the
vanilla
vanilla
JavaScript
javascript
option,
option
that
that
gives
gives
us
us
a
a
simple
simple
project
project
to
to
get
get
started
started
in.
in
Then
then
I'll
i'll
add
add
the
the
Jest
jest
testing
testing
framework
framework
to
to
it
it
by
by
running
running
npm
npm
install
install
jest,
jest
which
which
itself
itself
will
will
be
be
looking
looking
for
for
any
any
files
files
in
in
your
your
project
project
that
that
end
end
in
in
dot
dot
test
test
dotjs.
dotjs
Let's
let's
go
go
ahead
ahead
and
and
create
create
a
a
test
test
directory,
directory
then
then
add
add
a
a
testing
testing
file
file
to
to
it.
it
To
to
keep
keep
things
things
simple,
simple
I'm
i'm
going
going
to
to
implement
implement
our
our
code
code
and
and
also
also
test
test
it
it
in
in
the
the
stack
stack
dot
dot
test
test
dotjs
dotjs
file.
file
Now
now
to
to
run
run
the
the
code
code
in
in
this
this
file,
file
we
we
need
need
to
to
execute
execute
the
the
Jest
jest
test
test
runner.
runner
We
we
can
can
do
do
that
that
by
by
going
going
to
to
our
our
package.
package
Json
json
and
and
setting
setting
up
up
a
a
new
new
npm
npm
script
script
called
called
test
test
that
that
runs
runs
the
the
Jest
jest
command.
command
In
in
addition,
addition
I'll
i'll
add
add
the
the
watch
watch
all
all
command
command
to
to
have
have
Jest
jest
watch
watch
our
our
code
code
in
in
the
the
background
background
and
and
rerun
rerun
the
the
test
test
anytime
anytime
it
it
changes,
changes
and
and
also
also
the
the
verbose
verbose
flag
flag
to
to
add
add
some
some
extra
extra
output
output
to
to
the
the
terminal.
terminal
Go
go
ahead
ahead
and
and
run
run
npm
npm
test
test
from
from
the
the
command
command
line
line
and
and
you
you
should
should
get
get
your
your
first
first
failing
failing
test
test
because
because
it's
it's
detecting
detecting
that
that
file,
file
but
but
we
we
haven't
haven't
actually
actually
written
written
any
any
code
code
there
there
yet.
yet
One
one
other
other
optional,
optional
but
but
highly
highly
recommended
recommended
thing
thing
we
we
can
can
do
do
here
here
is
is
add
add
types
types
to
to
the
the
project
project
act
act
to
to
give
give
us
us
IntelliSense
intellisense
for
for
all
all
the
the
matchers
matchers
built
built
into
into
Jest,
jest
install
install
the
the
types
types
using
using
npm,
npm
then
then
create
create
a
a
Jsconfig.
jsconfig
Json
json
file
file
that
that
has
has
a
a
type
type
position
position
property
property
for
for
Jest.
jest
This
this
will
will
allow
allow
Versus
versus
Code
code
to
to
provide
provide
IntelliSense
intellisense
for
for
everything
everything
built
built
into
into
Jest,
jest
making
making
your
your
life
life
way
way
easier.
easier
One
one
other
other
random
random
pro
pro
tip
tip
I'll
i'll
throw
throw
out
out
there,
there
is
is
that
that
you
you
may
may
also
also
want
want
to
to
install
install
the
the
Wallaby
wallaby
plugin.
plugin
It's
it's
a
a
paid
paid
Versus
versus
Code
code
extension
extension
with
with
a
a
free
free
trial,
trial
but
but
it
it
will
will
tell
tell
you
you
whether
whether
or
or
not
not
your
your
tests
tests
are
are
passing
passing
directly
directly
in
in
the
the
editor
editor
without
without
having
having
to
to
look
look
at
at
the
the
terminal
terminal
and
and
that
that
can
can
give
give
you
you
a
a
really
really
nice
nice
productivity
productivity
boost.
boost
I'm
i'm
going
going
to
to
use
use
the
the
terminal
terminal
in
in
this
this
video,
video
but
but
Wallaby
wallaby
is
is
nice
nice
enough
enough
to
to
provide
provide
us
us
with
with
a
a
discount,
discount
so
so
feel
feel
free
free
to
to
check
check
that
that
out
out
in
in
the
the
description
description
below.
below
And
and
now
now
we're
we're
ready
ready
to
to
proceed
proceed
with
with
our
our
interview.
interview
The
the
first
first
thing
thing
I'll
i'll
do
do
is
is
use
use
the
the
describe
describe
function
function
engine
engine
to
to
describe
describe
the
the
thing
thing
it
it
is
is
that
that
I'm
i'm
testing,
testing
which
which
in
in
this
this
case
case
is
is
the
the
stack.
stack
It
it
takes
takes
a
a
callback
callback
function
function
as
as
the
the
second
second
argument,
argument
inside
inside
of
of
which
which
we
we
can
can
define
define
multiple
multiple
individual
individual
tests
tests
by
by
using
using
the
the
test
test
function
function
or
or
it,
it
both
both
of
of
which
which
do
do
the
the
exact
exact
same
same
thing.
thing
We'll
we'll
create
create
a
a
very
very
simple
simple
test
test
suite
suite
here
here
with
with
only
only
3
3
requirement,
requirement
we'll
we'll
wanna
wanna
make
make
sure
sure
that
that
our
our
stack
stack
is
is
created
created
empty,
empty
that
that
it
it
can
can
push
push
items
items
to
to
the
the
top,
top
and
and
it
it
can
can
also
also
pop
pop
or
or
remove
remove
items
items
from
from
the
the
top.
top
At
at
this
this
point,
point
if
if
we
we
go
go
ahead
ahead
and
and
save
save
the
the
file,
file
we
we
should
should
get
get
a
a
failing
failing
test
test
suite
suite
because
because
we've
we've
only
only
described
described
our
our
requirements
requirements
and
and
haven't
haven't
actually
actually
implemented
implemented
any
any
testing
testing
code
code
yet.
yet
In
in
some
some
cases,
cases
you
you
may
may
want
want
to
to
hold
hold
off
off
on
on
the
the
test
test
implementation,
implementation
in
in
which
which
case
case
you
you
can
can
use
use
the
the
to
to
do
do
method
method
to
to
make
make
the
the
test
test
pass
pass
while
while
you
you
figure
figure
things
things
out.
out
Now
now
let's
let's
go
go
ahead
ahead
and
and
implement
implement
our
our
first
first
test.
test
The
the
main
main
goal
goal
of
of
the
the
first
first
test
test
is
is
to
to
ensure
ensure
that
that
our
our
stack
stack
can
can
be
be
instantiated
instantiated
with
with
a
a
valid
valid
date,
date
let's
let's
go
go
ahead
ahead
and
and
instantiate
instantiate
a
a
class
class
that
that
doesn't
doesn't
exist
exist
to
to
represent
represent
the
the
object
object
that
that
we
we
want
want
to
to
test.
test
From
from
there,
there
we'll
we'll
use
use
expect
expect
to
to
to
to
write
write
an
an
expectation
expectation
to
to
make
make
sure
sure
that
that
our
our
code
code
does
does
what
what
is
is
expected.
expected
It
it
should
should
have
have
a
a
top
top
property
property
that
that
represents
represents
the
the
index
index
of
of
the
the
item
item
at
at
the
the
top
top
of
of
the
the
pack.
pack
Because
because
it's
it's
empty
empty
when
when
it's
it's
first
first
created,
created
the
the
value
value
should
should
be
be
negative
negative
1.
1
2
2
b
b
is
is
a
a
matcher
matcher
that
that
will
will
test
test
the
the
actual
actual
value
value
to
to
the
the
correct
correct
value.
value
Now,
now
here's
here's
where
where
test
test
driven
driven
development
development
starts
starts
to
to
get
get
really
really
cool.
cool
Go
go
ahead
ahead
and
and
save
save
the
the
file
file
and
and
you'll
you'll
notice
notice
that
that
we
we
get
get
a
a
failing
failing
test.
test
If
if
we
we
look
look
at
at
the
the
output
output
closely,
closely
date,
date
it'll
it'll
tell
tell
us
us
exactly
exactly
which
which
line
line
of
of
code
code
failed
failed
and
and
why.
why
It
it
says
says
reference
reference
error,
error
stack
stack
is
is
not
not
defined.
defined
We
we
can
can
use
use
that
that
feedback
feedback
as
as
a
a
starting
starting
point
point
to
to
start
start
implementing
implementing
our
our
code.
code
To
to
to
to
address
address
the
the
error,
error
we'll
we'll
first
first
need
need
to
to
define
define
a
a
class
class
called
called
stack.
stack
Go
go
ahead
ahead
and
and
define
define
it,
it
then
then
save
save
the
the
file,
file
then
then
you'll
you'll
notice
notice
that
that
we
we
still
still
get
get
a
a
failing
failing
test,
test
but
but
this
this
time
time
it
it
goes
goes
down
down
to
to
the
the
expectation
expectation
telling
telling
us
us
that
that
it
it
expected
expected
negative
negative
one,
one
but
but
received
received
undefined
undefined
as
as
the
the
return
return
value.
value
To
to
address
address
that
that
issue,
issue
we
we
need
need
to
to
add
add
a
a
constructor
constructor
to
to
the
the
class
class
to
to
initialize
initialize
it
it
with
with
the
the
proper
proper
data.
data
Let's
let's
give
give
it
it
a
a
top
top
value
value
of
of
0
0
and
and
then
then
we'll
we'll
also
also
define
define
an
an
item's
item's
property
property
here
here
to
to
represent
represent
the
the
stack
stack
itself
itself
as
as
an
an
empty
empty
object.
object
Because
because
remember,
remember
we're
we're
not
not
allowed
allowed
to
to
use
use
arrays
arrays
in
in
this
this
problem.
problem
Go
go
ahead
ahead
and
and
save
save
the
the
file,
file
And
and
now
now
we
we
finally
finally
get
get
a
a
passing
passing
test.
test
You
you
can
can
also
also
add
add
multiple
multiple
expectations
expectations
to
to
a
a
single
single
test.
test
Let's
let's
go
go
ahead
ahead
and
and
test
test
the
the
stack
stack
back
back
items
items
property
property
to
to
make
make
sure
sure
that
that
it's
it's
an
an
empty
empty
object.
object
But
but
when
when
we
we
do
do
that,
that
you'll
you'll
notice
notice
that
that
we
we
now
now
get
get
a
a
failing
failing
test,
test
even
even
though
though
we're
we're
definitely
definitely
comparing
comparing
an
an
empty
empty
object
object
to
to
an
an
empty
empty
object.
object
And
and
it's
it's
actually
actually
not
not
an
an
issue
issue
with
with
our
our
implementation,
implementation
but
but
an
an
issue
issue
with
with
the
the
test
test
itself.
itself
The
the
2
2
b
b
matcher
matcher
checks
checks
for
for
referentially
referentially
quality
quality
between
between
2
2
objects.
objects
In
in
this
this
case,
case
both
both
objects
objects
are
are
empty,
empty
but
but
they're
they're
2
2
different
different
objects
objects
in
in
memory
memory
which
which
is
is
causing
causing
the
the
test
test
to
to
fail.
fail
What
what
we
we
need
need
to
to
do
do
here
here
is
is
use
use
a
a
different
different
matcher.
matcher
The
the
to
to
equal
equal
matcher
matcher
would
would
be
be
a
a
better
better
choice
choice
because
because
it
it
checks
checks
for
for
value
value
equality
equality
instead
instead
of
of
the
the
object
object
reference
reference
itself.
itself
An
an
important
important
takeaway
takeaway
here
here
is
is
that
that
it's
it's
not
not
always
always
your
your
main
main
application
application
code
code
that's
that's
the
the
problem,
problem
it
it
might
might
be
be
a
a
bug
bug
in
in
the
the
test
test
itself
itself
And
and
unfortunately,
unfortunately
we
we
don't
don't
write
write
tests
tests
for
for
our
our
tests.
tests
Now
now
let's
let's
move
move
on
on
to
to
our
our
second
second
test
test
to
to
see
see
if
if
a
a
stack
stack
can
can
push
push
an
an
item
item
to
to
the
the
top.
top
What
what
What
what
you'll
you'll
notice
notice
is
is
that
that
the
the
first
first
thing
thing
I'm
i'm
doing
doing
is
is
initializing
initializing
a
a
new
new
stack
stack
just
just
like
like
we
we
did
did
in
in
the
the
previous
previous
test,
test
but
but
there's
there's
actually
actually
a
a
more
more
efficient
efficient
way
way
to
to
do
do
this.
this
Jest
jest
has
has
a
a
set
set
of
of
helper
helper
functions
functions
for
for
setup
setup
and
and
teardown.
teardown
These
these
are
are
really
really
useful
useful
because
because
code
code
duplication
duplication
can
can
get
get
really
really
bad
bad
inside
inside
of
of
a
a
test
test
suite.
suite
For
for
example,
example
we
we
might
might
set
set
up
up
a
a
global
global
variable
variable
for
for
the
the
stack,
stack
then
then
use
use
the
the
before
before
each
each
hook
hook
to
to
reinitialize
reinitialize
it
it
before
before
each
each
new
new
test.
test
That'll
that'll
give
give
us
us
an
an
empty
empty
object
object
to
to
work
work
work
work
with
with
before
before
each
each
test
test
so
so
we
we
don't
don't
have
have
to
to
set
set
it
it
up
up
manually
manually
in
in
each
each
one.
one
Now
now
going
going
into
into
our
our
second
second
test,
test
we'll
we'll
call
call
the
the
push
push
method
method
with
with
an
an
item
item
and
and
then
then
we'll
we'll
expect
expect
the
the
top
top
value
value
to
to
be
be
incremented
incremented
by
by
1
1
and
and
we'll
we'll
add
add
a
a
peak
peak
property
property
to
to
get
get
the
the
top
top
of
of
the
the
stack
stack
and
and
we'll
we'll
expect
expect
like
like
that
that
value
value
to
to
equal
equal
the
the
value
value
that
that
we
we
just
just
pushed
pushed
to
to
it.
it
That'll
that'll
give
give
us
us
a
a
failing
failing
test
test
and
and
then
then
we
we
can
can
once
once
again
again
go
go
into
into
our
our
source
source
code
code
and
and
start
start
implementing
implementing
the
the
features
features
needed
needed
to
to
get
get
to
to
a
a
passing
passing
test.
test
In
in
general,
general
what
what
you'll
you'll
wanna
wanna
do
do
here
here
is
is
try
try
to
to
get
get
to
to
a
a
passing
passing
test
test
as
as
soon
soon
as
as
possible.
possible
Once
once
you
you
have
have
that
that
passing
passing
test,
test
you
you
can
can
then
then
go
go
back
back
and
and
refactor
refactor
and
and
look
look
for
for
optimizations
optimizations
to
to
make
make
while
while
trying
trying
to
to
keep
keep
your
your
test
test
in
in
the
the
green.
green
There's
there's
just
just
something
something
very
very
psychologically
psychologically
satisfying
satisfying
when
when
you
you
go
go
from
from
a
a
red
red
failing
failing
test
test
to
to
a
a
green
green
passing
passing
test.
test
My
my
challenge
challenge
to
to
you
you
is
is
to
to
now
now
implement
implement
the
the
final
final
requirement
requirement
in
in
the
the
test
test
suite.
suite
Try
try
to
to
use
use
test
test
driven
driven
development
development
to
to
implement
implement
a
a
feature
feature
that
that
can
can
pop
pop
an
an
item
item
off
off
of
of
the
the
stack.
stack
Speaking
speaking
of
of
psychologically
psychologically
satisfying,
satisfying
another
another
thing
thing
you
you
can
can
do
do
is
is
run
run
a
a
code
code
coverage
coverage
report,
report
which
which
will
will
give
give
you
you
an
an
idea
idea
of
of
how
how
well
well
your
your
tests
tests
cover
cover
your
your
actual
actual
source
source
code.
code
Back
back
in
in
the
the
package
package
JSON,
json
add
add
the
the
coverage
coverage
flag
flag
to
to
the
the
jest
jest
command,
command
rerun
rerun
it,
it
then
then
You'll
you'll
get
get
this
this
report
report
generated
generated
that
that
tells
tells
you
you
the
the
percentage
percentage
of
of
code
code
covered
covered
by
by
your
your
test
test
suite.
suite
That
that
can
can
be
be
useful
useful
at
at
times,
times
but
but
mostly
mostly
it
it
just
just
gives
gives
you
you
a
a
full
full
sense
sense
of
of
security.
security
Geek.
geek
100%
100%
code
code
coverage
coverage
doesn't
doesn't
mean
mean
that
that
you
you
have
have
a
a
good
good
test
test
suite,
suite
but
but
it
it
may
may
be
be
a
a
good
good
thing
thing
to
to
show
show
your
your
product
product
manager
manager
or
or
client.
client
What
what
I
i
wanna
wanna
show
show
you
you
next
next
is
is
a
a
lot
lot
more
more
fun
fun
and
and
interesting
interesting
and
and
that
that
is
is
end
end
to
to
end
end
testing.
testing
Unlike
unlike
a
a
unit
unit
test,
test
which
which
is
is
designed
designed
to
to
be
be
fast
fast
and
and
simple,
simple
an
an
end
end
to
to
end
end
test
test
is
is
very
very
long
long
and
and
complex
complex
and
and
takes
takes
a
a
while
while
to
to
run
run
because
because
it
it
simulates
simulates
actual
actual
user
user
behaviors
behaviors
in
in
the
the
browser.
browser
We
we
could
could
write
write
our
our
end
end
to
to
end
end
test
test
with
with
Jest,
jest
utilizing
utilizing
that
that
puppeteer
puppeteer
package.
package
However,
however
my
my
favorite
favorite
way
way
to
to
write
write
end
end
to
to
end
end
test
test
is
is
with
with
a
a
tool
tool
called
called
Cypress.
cypress
Install
install
it
it
by
by
running
running
npm
npm
install
install
Cypress,
cypress
and
and
this
this
will
will
take
take
a
a
few
few
minutes
minutes
speed
speed
because
because
it's
it's
downloading
downloading
an
an
actual
actual
browser
browser
that
that
will
will
run
run
your
your
tests
tests
in
in
a
a
real
real
world
world
environment.
environment
When
when
the
the
installation
installation
is
is
complete,
complete
we
we
can
can
go
go
into
into
our
our
package.
package
Json
json
and
and
add
add
an
an
end
end
to
to
end
end
script
script
that
that
runs
runs
the
the
Cypress
cypress
open
open
command.
command
That
that
should
should
open
open
up
up
the
the
test
test
runner
runner
which
which
comes
comes
with
with
a
a
bunch
bunch
of
of
built
built
in
in
examples.
examples
If
if
You
you
click
click
on
on
the
the
actions
actions
example,
example
you'll
you'll
notice
notice
it
it
starts
starts
running
running
a
a
test
test
suite
suite
by
by
filling
filling
out
out
a
a
form,
form
clicking
clicking
on
on
buttons,
buttons
and
and
doing
doing
all
all
kinds
kinds
of
of
other
other
stuff.
stuff
When
when
I
i
use
use
Cypress
cypress
for
for
my
my
own
own
projects,
projects
I
i
use
use
the
the
Firebase
firebase
Emulator
emulator
to
to
create
create
a
a
mock
mock
database
database
and
and
mock
mock
user
user
authentication,
authentication
which
which
allows
allows
me
me
to
to
test
test
my
my
apps
apps
efficiently
efficiently
in
in
an
an
environment
environment
that
that
is
is
very
very
similar
similar
to
to
how
how
they'll
they'll
look
look
in
in
production.
production
Now,
now
if
if
we
we
go
go
back
back
into
into
our
our
source
source
code,
code
you'll
you'll
notice
notice
that
that
a
a
Cypress
cypress
directory
directory
was
was
created.
created
We
we
can
can
find
find
that
that
source
source
mode
mode
for
for
this
this
example
example
test
test
by
by
going
going
to
to
the
the
integration
integration
folder,
folder
to
to
the
the
actions
actions
dot
dot
spec
spec
file.
file
And
and
just
just
like
like
in
in
Jest,
jest
We
we
first
first
define
define
a
a
test
test
suite,
suite
then
then
inside
inside
of
of
it,
it
we
we
have
have
multiple
multiple
tests
tests
with
with
the
the
it
it
keyword.
keyword
Now
now
the
the
cool
cool
thing
thing
about
about
Cypress
cypress
is
is
that
that
it
it
makes
makes
it
it
very
very
easy
easy
to
to
code
code
these
these
automated
automated
interactions
interactions
with
with
your
your
website.
website
It
it
has
has
a
a
Jquery
jquery
like
like
syntax
syntax
that
that
allows
allows
you
you
to
to
match
match
a
a
DOM
dom
element,
element
like,
like
say,
say
a
a
form
form
input,
input
then
then
type
type
into
into
it
it
with
with
whatever
whatever
text
text
you
you
provide.
provide
You
you
can
can
then
then
run
run
expectations
expectations
with
with
should
should
to
to
ensure
ensure
that
that
it
it
has
has
the
the
proper
proper
value,
value
CSS
css
style,
style
or
or
whatever
whatever
else
else
is
is
important
important
in
in
the
the
UI.
ui
It's
it's
a
a
really
really
awesome
awesome
tool
tool
and
and
I'm
i'm
not
not
sponsored
sponsored
by
by
them
them
in
in
any
any
way.
way
But
but
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
If
if
this
this
video
video
helped
helped
you,
you
please
please
like
like
and
and
subscribe,
subscribe
and
and
consider
consider
becoming
becoming
a
a
pro
pro
member
member
to
to
get
get
access
access
to
to
more
more
advanced
advanced
content.
content
Thanks
thanks
watching
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speaker explains the concept of Test Driven Development and provides a video on various testing strategies. They also suggest installing the WAV plugin and provide a discount for the interview. The speaker discusses various terms and conditions for developers, including acceptance testing, system testing, and stress testing, and provides tips on how to implement code and test projects. They recommend using the test suite and suggest starting with a test code, using the tool called Cypress, and starting with a test code.
Test-Driven Development // Fun TDD Introduction with JavaScript
Red, green, refactor. Imagine you're sitting in a technical interview for an entry level web developer job and they ask you to implement a dynamic time warping algorithm to measure the similarity between 2 sequences in logarithmic time. Instead of freaking out and wondering what this has to do with jQuery, you can just Say, no problem. Let me write a few test cases for that first. Not only will that buy you some time, but it also makes you look like you know what you're doing. Test driven development is a technique where you describe behavior of your code before you go and implement it. If you trust the science, testing will help reduce bugs and improve the maintainability of your code base in the long run. And if you're new to programming, knowing how to test your code is one of the most powerful ways to level up as a developer. Not only is it fun, but it will also teach you about your code in unexpected ways and and make you much better at debugging it. Today's video will teach you everything you need to know to get started with software testing as a developer. We'll talk about a bunch of different testing strategies from a high level, then take a a hands on approach by implementing unit tests from scratch with Jest. And we'll also look at end to end testing with a tool called Cypress. But most importantly, by the end of the video, you'll learn why testing is valuable and how to make the decision about whether or not you should test something, because it's a practice that walks a very fine line between being valuable and a complete waste of time. Before we get started, make sure to hit the like button and subscribe. In the last video, I explained how software testing works. But if you missed it, automated testing is basically just a way to write code that describes to your requirements and validates your main application code. Now, most developers I know, and myself included, generally don't start writing tests until we have a working feature, or maybe we just don't write any tests at all. And that's especially true with front end development because UI requirements tend to change frequently. But if you follow the principle of Test Driven Development, You'll write your test before you implement your actual code. And a common mantra is red, green, refactor, which means you write a failing test first, red, then you write some code to get it passing, green, then you go back and optimize or refactor the code. It's not always practical to do this, but if you have a project with very clear requirements, you might find that TDD actually improves your productivity. Now, let's take a look at a bunch of different testing strategies and see how they add value to a code base. At the lowest level, we dev unit testing, where the goal is to validate the behavior of individual functions, methods, or just units of code. We'll get hands on with unit testing in just a minute. The next level up is integration testing, which involves testing multiple units of code together. For example, you might have a React component and a hook to fetch something from a database. You can unit test each of these individually, but then have an integration test to see how well they work together. Like, is the component actually able to Use the hook to get the data that it needs for the UI. From there, we have end to end testing, which runs your app in a simulated environment and attempts to emulate actual user behavior. There's a really awesome tool called Cypress that has a browser based test runner that allows you to program tests where users click on of buttons, fill out forms, then assert that the actual changes to the DOM or the UI are valid. Personally, I find end to end tests to be the most valuable ones that I write. So make sure to stay tuned until the end of this video to see Cypress in action. In my opinion, these three testing strategies are the most important ones to know, but there are a lot of other terms that get thrown out there that you may wanna be familiar with. Acceptance testing is a form of testing that makes sure that the software meets all of the client's requirements. Stamp. Then you have system testing to ensure that everything works on actual servers or hardware. Then you have things like sanity or smoke test. On a large application, you may have thousands of tests to run, and this can actually take a very long time and delay everybody else's work. A smoke test runs a few of the most important tests burst to make sure the app isn't on fire before proceeding with the rest of the test suite. Now at this point, we've only looked at functional testing, but there are also non functional tests support things like performance, usability, and security. You'll often hear terms like stress testing or failover testing, which are used to test the capabilities of the infrastructure sure as opposed to the code itself. Now that you know what all this fancy testing jargon means, let's get our hands dirty in JavaScript by pretending that we're in an actual technical interview. We're required to implement a stack data structure where the last item in is the first item out. It's very similar to an array, but we have to implement it without using a JavaScript array. Now before we can start, we need to initialize a project and keep in mind that you can find the source code for this on GitHub. I'm using Vite by running the npm init vitejs/app command, then selecting the vanilla JavaScript option, that gives us a simple project to get started in. Then I'll add the Jest testing framework to it by running npm install jest, which itself will be looking for any files in your project that end in dot test dotjs. Let's go ahead and create a test directory, then add a testing file to it. To keep things simple, I'm going to implement our code and also test it in the stack dot test dotjs file. Now to run the code in this file, we need to execute the Jest test runner. We can do that by going to our package. Json and setting up a new npm script called test that runs the Jest command. In addition, I'll add the watch all command to have Jest watch our code in the background and rerun the test anytime it changes, and also the verbose flag to add some extra output to the terminal. Go ahead and run npm test from the command line and you should get your first failing test because it's detecting that file, but we haven't actually written any code there yet. One other optional, but highly recommended thing we can do here is add types to the project act to give us IntelliSense for all the matchers built into Jest, install the types using npm, then create a Jsconfig. Json file that has a type position property for Jest. This will allow Versus Code to provide IntelliSense for everything built into Jest, making your life way easier. One other random pro tip I'll throw out there, is that you may also want to install the Wallaby plugin. It's a paid Versus Code extension with a free trial, but it will tell you whether or not your tests are passing directly in the editor without having to look at the terminal and that can give you a really nice productivity boost. I'm going to use the terminal in this video, but Wallaby is nice enough to provide us with a discount, so feel free to check that out in the description below. And now we're ready to proceed with our interview. The first thing I'll do is use the describe function engine to describe the thing it is that I'm testing, which in this case is the stack. It takes a callback function as the second argument, inside of which we can define multiple individual tests by using the test function or it, both of which do the exact same thing. We'll create a very simple test suite here with only 3 requirement, we'll wanna make sure that our stack is created empty, that it can push items to the top, and it can also pop or remove items from the top. At this point, if we go ahead and save the file, we should get a failing test suite because we've only described our requirements and haven't actually implemented any testing code yet. In some cases, you may want to hold off on the test implementation, in which case you can use the to do method to make the test pass while you figure things out. Now let's go ahead and implement our first test. The main goal of the first test is to ensure that our stack can be instantiated with a valid date, let's go ahead and instantiate a class that doesn't exist to represent the object that we want to test. From there, we'll use expect to to write an expectation to make sure that our code does what is expected. It should have a top property that represents the index of the item at the top of the pack. Because it's empty when it's first created, the value should be negative 1. 2 b is a matcher that will test the actual value to the correct value. Now, here's where test driven development starts to get really cool. Go ahead and save the file and you'll notice that we get a failing test. If we look at the output closely, date, it'll tell us exactly which line of code failed and why. It says reference error, stack is not defined. We can use that feedback as a starting point to start implementing our code. To to address the error, we'll first need to define a class called stack. Go ahead and define it, then save the file, then you'll notice that we still get a failing test, but this time it goes down to the expectation telling us that it expected negative one, but received undefined as the return value. To address that issue, we need to add a constructor to the class to initialize it with the proper data. Let's give it a top value of 0 and then we'll also define an item's property here to represent the stack itself as an empty object. Because remember, we're not allowed to use arrays in this problem. Go ahead and save the file, And now we finally get a passing test. You can also add multiple expectations to a single test. Let's go ahead and test the stack back items property to make sure that it's an empty object. But when we do that, you'll notice that we now get a failing test, even though we're definitely comparing an empty object to an empty object. And it's actually not an issue with our implementation, but an issue with the test itself. The 2 b matcher checks for referentially quality between 2 objects. In this case, both objects are empty, but they're 2 different objects in memory which is causing the test to fail. What we need to do here is use a different matcher. The to equal matcher would be a better choice because it checks for value equality instead of the object reference itself. An important takeaway here is that it's not always your main application code that's the problem, it might be a bug in the test itself And unfortunately, we don't write tests for our tests. Now let's move on to our second test to see if a stack can push an item to the top. What What you'll notice is that the first thing I'm doing is initializing a new stack just like we did in the previous test, but there's actually a more efficient way to do this. Jest has a set of helper functions for setup and teardown. These are really useful because code duplication can get really bad inside of a test suite. For example, we might set up a global variable for the stack, then use the before each hook to reinitialize it before each new test. That'll give us an empty object to work work with before each test so we don't have to set it up manually in each one. Now going into our second test, we'll call the push method with an item and then we'll expect the top value to be incremented by 1 and we'll add a peak property to get the top of the stack and we'll expect like that value to equal the value that we just pushed to it. That'll give us a failing test and then we can once again go into our source code and start implementing the features needed to get to a passing test. In general, what you'll wanna do here is try to get to a passing test as soon as possible. Once you have that passing test, you can then go back and refactor and look for optimizations to make while trying to keep your test in the green. There's just something very psychologically satisfying when you go from a red failing test to a green passing test. My challenge to you is to now implement the final requirement in the test suite. Try to use test driven development to implement a feature that can pop an item off of the stack. Speaking of psychologically satisfying, another thing you can do is run a code coverage report, which will give you an idea of how well your tests cover your actual source code. Back in the package JSON, add the coverage flag to the jest command, rerun it, then You'll get this report generated that tells you the percentage of code covered by your test suite. That can be useful at times, but mostly it just gives you a full sense of security. Geek. 100% code coverage doesn't mean that you have a good test suite, but it may be a good thing to show your product manager or client. What I wanna show you next is a lot more fun and interesting and that is end to end testing. Unlike a unit test, which is designed to be fast and simple, an end to end test is very long and complex and takes a while to run because it simulates actual user behaviors in the browser. We could write our end to end test with Jest, utilizing that puppeteer package. However, my favorite way to write end to end test is with a tool called Cypress. Install it by running npm install Cypress, and this will take a few minutes speed because it's downloading an actual browser that will run your tests in a real world environment. When the installation is complete, we can go into our package. Json and add an end to end script that runs the Cypress open command. That should open up the test runner which comes with a bunch of built in examples. If You click on the actions example, you'll notice it starts running a test suite by filling out a form, clicking on buttons, and doing all kinds of other stuff. When I use Cypress for my own projects, I use the Firebase Emulator to create a mock database and mock user authentication, which allows me to test my apps efficiently in an environment that is very similar to how they'll look in production. Now, if we go back into our source code, you'll notice that a Cypress directory was created. We can find that source mode for this example test by going to the integration folder, to the actions dot spec file. And just like in Jest, We first define a test suite, then inside of it, we have multiple tests with the it keyword. Now the cool thing about Cypress is that it makes it very easy to code these automated interactions with your website. It has a Jquery like syntax that allows you to match a DOM element, like, say, a form input, then type into it with whatever text you provide. You can then run expectations with should to ensure that it has the proper value, CSS style, or whatever else is important in the UI. It's a really awesome tool and I'm not sponsored by them in any way. But I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe, and consider becoming a pro member to get access to more advanced content. Thanks watching and I will see you in the next one.
The speaker explains the concept of Test Driven Development and provides a video on various testing strategies. They also suggest installing the WAV plugin and provide a discount for the interview. The speaker discusses various terms and conditions for developers, including acceptance testing, system testing, and stress testing, and provides tips on how to implement code and test projects. They recommend using the test suite and suggest starting with a test code, using the tool called Cypress, and starting with a test code.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Test-Driven Development // Fun TDD Introduction with JavaScript 
        and a small summary : The speaker explains the concept of Test Driven Development and provides a video on various testing strategies. They also suggest installing the WAV plugin and provide a discount for the interview. The speaker discusses various terms and conditions for developers, including acceptance testing, system testing, and stress testing, and provides tips on how to implement code and test projects. They recommend using the test suite and suggest starting with a test code, using the tool called Cypress, and starting with a test code.
        [/INST]
        
        Generate the video : Red, green, refactor. Imagine you're sitting in a technical interview for an entry level web developer job and they ask you to implement a dynamic time warping algorithm to measure the similarity between 2 sequences in logarithmic time. Instead of freaking out and wondering what this has to do with jQuery, you can just Say, no problem. Let me write a few test cases for that first. Not only will that buy you some time, but it also makes you look like you know what you're doing. Test driven development is a technique where you describe behavior of your code before you go and implement it. If you trust the science, testing will help reduce bugs and improve the maintainability of your code base in the long run. And if you're new to programming, knowing how to test your code is one of the most powerful ways to level up as a developer. Not only is it fun, but it will also teach you about your code in unexpected ways and and make you much better at debugging it. Today's video will teach you everything you need to know to get started with software testing as a developer. We'll talk about a bunch of different testing strategies from a high level, then take a a hands on approach by implementing unit tests from scratch with Jest. And we'll also look at end to end testing with a tool called Cypress. But most importantly, by the end of the video, you'll learn why testing is valuable and how to make the decision about whether or not you should test something, because it's a practice that walks a very fine line between being valuable and a complete waste of time. Before we get started, make sure to hit the like button and subscribe. In the last video, I explained how software testing works. But if you missed it, automated testing is basically just a way to write code that describes to your requirements and validates your main application code. Now, most developers I know, and myself included, generally don't start writing tests until we have a working feature, or maybe we just don't write any tests at all. And that's especially true with front end development because UI requirements tend to change frequently. But if you follow the principle of Test Driven Development, You'll write your test before you implement your actual code. And a common mantra is red, green, refactor, which means you write a failing test first, red, then you write some code to get it passing, green, then you go back and optimize or refactor the code. It's not always practical to do this, but if you have a project with very clear requirements, you might find that TDD actually improves your productivity. Now, let's take a look at a bunch of different testing strategies and see how they add value to a code base. At the lowest level, we dev unit testing, where the goal is to validate the behavior of individual functions, methods, or just units of code. We'll get hands on with unit testing in just a minute. The next level up is integration testing, which involves testing multiple units of code together. For example, you might have a React component and a hook to fetch something from a database. You can unit test each of these individually, but then have an integration test to see how well they work together. Like, is the component actually able to Use the hook to get the data that it needs for the UI. From there, we have end to end testing, which runs your app in a simulated environment and attempts to emulate actual user behavior. There's a really awesome tool called Cypress that has a browser based test runner that allows you to program tests where users click on of buttons, fill out forms, then assert that the actual changes to the DOM or the UI are valid. Personally, I find end to end tests to be the most valuable ones that I write. So make sure to stay tuned until the end of this video to see Cypress in action. In my opinion, these three testing strategies are the most important ones to know, but there are a lot of other terms that get thrown out there that you may wanna be familiar with. Acceptance testing is a form of testing that makes sure that the software meets all of the client's requirements. Stamp. Then you have system testing to ensure that everything works on actual servers or hardware. Then you have things like sanity or smoke test. On a large application, you may have thousands of tests to run, and this can actually take a very long time and delay everybody else's work. A smoke test runs a few of the most important tests burst to make sure the app isn't on fire before proceeding with the rest of the test suite. Now at this point, we've only looked at functional testing, but there are also non functional tests support things like performance, usability, and security. You'll often hear terms like stress testing or failover testing, which are used to test the capabilities of the infrastructure sure as opposed to the code itself. Now that you know what all this fancy testing jargon means, let's get our hands dirty in JavaScript by pretending that we're in an actual technical interview. We're required to implement a stack data structure where the last item in is the first item out. It's very similar to an array, but we have to implement it without using a JavaScript array. Now before we can start, we need to initialize a project and keep in mind that you can find the source code for this on GitHub. I'm using Vite by running the npm init vitejs/app command, then selecting the vanilla JavaScript option, that gives us a simple project to get started in. Then I'll add the Jest testing framework to it by running npm install jest, which itself will be looking for any files in your project that end in dot test dotjs. Let's go ahead and create a test directory, then add a testing file to it. To keep things simple, I'm going to implement our code and also test it in the stack dot test dotjs file. Now to run the code in this file, we need to execute the Jest test runner. We can do that by going to our package. Json and setting up a new npm script called test that runs the Jest command. In addition, I'll add the watch all command to have Jest watch our code in the background and rerun the test anytime it changes, and also the verbose flag to add some extra output to the terminal. Go ahead and run npm test from the command line and you should get your first failing test because it's detecting that file, but we haven't actually written any code there yet. One other optional, but highly recommended thing we can do here is add types to the project act to give us IntelliSense for all the matchers built into Jest, install the types using npm, then create a Jsconfig. Json file that has a type position property for Jest. This will allow Versus Code to provide IntelliSense for everything built into Jest, making your life way easier. One other random pro tip I'll throw out there, is that you may also want to install the Wallaby plugin. It's a paid Versus Code extension with a free trial, but it will tell you whether or not your tests are passing directly in the editor without having to look at the terminal and that can give you a really nice productivity boost. I'm going to use the terminal in this video, but Wallaby is nice enough to provide us with a discount, so feel free to check that out in the description below. And now we're ready to proceed with our interview. The first thing I'll do is use the describe function engine to describe the thing it is that I'm testing, which in this case is the stack. It takes a callback function as the second argument, inside of which we can define multiple individual tests by using the test function or it, both of which do the exact same thing. We'll create a very simple test suite here with only 3 requirement, we'll wanna make sure that our stack is created empty, that it can push items to the top, and it can also pop or remove items from the top. At this point, if we go ahead and save the file, we should get a failing test suite because we've only described our requirements and haven't actually implemented any testing code yet. In some cases, you may want to hold off on the test implementation, in which case you can use the to do method to make the test pass while you figure things out. Now let's go ahead and implement our first test. The main goal of the first test is to ensure that our stack can be instantiated with a valid date, let's go ahead and instantiate a class that doesn't exist to represent the object that we want to test. From there, we'll use expect to to write an expectation to make sure that our code does what is expected. It should have a top property that represents the index of the item at the top of the pack. Because it's empty when it's first created, the value should be negative 1. 2 b is a matcher that will test the actual value to the correct value. Now, here's where test driven development starts to get really cool. Go ahead and save the file and you'll notice that we get a failing test. If we look at the output closely, date, it'll tell us exactly which line of code failed and why. It says reference error, stack is not defined. We can use that feedback as a starting point to start implementing our code. To to address the error, we'll first need to define a class called stack. Go ahead and define it, then save the file, then you'll notice that we still get a failing test, but this time it goes down to the expectation telling us that it expected negative one, but received undefined as the return value. To address that issue, we need to add a constructor to the class to initialize it with the proper data. Let's give it a top value of 0 and then we'll also define an item's property here to represent the stack itself as an empty object. Because remember, we're not allowed to use arrays in this problem. Go ahead and save the file, And now we finally get a passing test. You can also add multiple expectations to a single test. Let's go ahead and test the stack back items property to make sure that it's an empty object. But when we do that, you'll notice that we now get a failing test, even though we're definitely comparing an empty object to an empty object. And it's actually not an issue with our implementation, but an issue with the test itself. The 2 b matcher checks for referentially quality between 2 objects. In this case, both objects are empty, but they're 2 different objects in memory which is causing the test to fail. What we need to do here is use a different matcher. The to equal matcher would be a better choice because it checks for value equality instead of the object reference itself. An important takeaway here is that it's not always your main application code that's the problem, it might be a bug in the test itself And unfortunately, we don't write tests for our tests. Now let's move on to our second test to see if a stack can push an item to the top. What What you'll notice is that the first thing I'm doing is initializing a new stack just like we did in the previous test, but there's actually a more efficient way to do this. Jest has a set of helper functions for setup and teardown. These are really useful because code duplication can get really bad inside of a test suite. For example, we might set up a global variable for the stack, then use the before each hook to reinitialize it before each new test. That'll give us an empty object to work work with before each test so we don't have to set it up manually in each one. Now going into our second test, we'll call the push method with an item and then we'll expect the top value to be incremented by 1 and we'll add a peak property to get the top of the stack and we'll expect like that value to equal the value that we just pushed to it. That'll give us a failing test and then we can once again go into our source code and start implementing the features needed to get to a passing test. In general, what you'll wanna do here is try to get to a passing test as soon as possible. Once you have that passing test, you can then go back and refactor and look for optimizations to make while trying to keep your test in the green. There's just something very psychologically satisfying when you go from a red failing test to a green passing test. My challenge to you is to now implement the final requirement in the test suite. Try to use test driven development to implement a feature that can pop an item off of the stack. Speaking of psychologically satisfying, another thing you can do is run a code coverage report, which will give you an idea of how well your tests cover your actual source code. Back in the package JSON, add the coverage flag to the jest command, rerun it, then You'll get this report generated that tells you the percentage of code covered by your test suite. That can be useful at times, but mostly it just gives you a full sense of security. Geek. 100% code coverage doesn't mean that you have a good test suite, but it may be a good thing to show your product manager or client. What I wanna show you next is a lot more fun and interesting and that is end to end testing. Unlike a unit test, which is designed to be fast and simple, an end to end test is very long and complex and takes a while to run because it simulates actual user behaviors in the browser. We could write our end to end test with Jest, utilizing that puppeteer package. However, my favorite way to write end to end test is with a tool called Cypress. Install it by running npm install Cypress, and this will take a few minutes speed because it's downloading an actual browser that will run your tests in a real world environment. When the installation is complete, we can go into our package. Json and add an end to end script that runs the Cypress open command. That should open up the test runner which comes with a bunch of built in examples. If You click on the actions example, you'll notice it starts running a test suite by filling out a form, clicking on buttons, and doing all kinds of other stuff. When I use Cypress for my own projects, I use the Firebase Emulator to create a mock database and mock user authentication, which allows me to test my apps efficiently in an environment that is very similar to how they'll look in production. Now, if we go back into our source code, you'll notice that a Cypress directory was created. We can find that source mode for this example test by going to the integration folder, to the actions dot spec file. And just like in Jest, We first define a test suite, then inside of it, we have multiple tests with the it keyword. Now the cool thing about Cypress is that it makes it very easy to code these automated interactions with your website. It has a Jquery like syntax that allows you to match a DOM element, like, say, a form input, then type into it with whatever text you provide. You can then run expectations with should to ensure that it has the proper value, CSS style, or whatever else is important in the UI. It's a really awesome tool and I'm not sponsored by them in any way. But I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe, and consider becoming a pro member to get access to more advanced content. Thanks watching and I will see you in the next one.
        