As mentioned in the previous video, you can test small pieces of code or follow complex user flows, and also everything in between. In the testing world, there are some broadly used terms to describe those pieces. Testing small pieces are called unit tests. Testing more complex flows are often called or referred to as acceptance tests or end-to-end tests.
And things in between often fall into the category of integration or functional tests. To make this lesson a little more practical, let's create a short unit test example from scratch. Here we have the user. This is a simple user class that just gives us a constructor and we have a get parameter to call the name directly there.
So how would we approach testing this class? So first of all, let's write the test directly in this file and we create a test function. Okay, so we want this function to actually run and verify that the code is working. So the first thing we need is basically we need to create a new user to have some kind of data to verify what's going on.
So let's create this new user. Okay, so we create a new user, we define the user details upfront, and then say, let's define the test user and we just create a new user instance using the user details that we just created. Let's just verify that this one is actually working and giving us the correct name in return. We will do this with a simple console log function.
So this is our console log function. In order to see that everything works as expected, we need to execute this test. In this case, I just call it. Ideally, in this case, I'm going to use node to execute the test on the command line, but you can do this in any browser as well.
Perfect. Here we see that our username is correct and printout true. If I would change the name here and rerun the code, I would actually see that the username is no longer correct. So here we created a very simple test without any helper tools, but it verifies that the user class is actually working as intended.
Besides this not being the most practical way of writing a test, it would give us insight into the user class working as expected. But let's proceed. If you search for types of testing further, you might probably very soon stumble over the testing pyramid. It would look something like this.
This is a very idealized concept of how many tests of which type should be in the system. In the real world, this often does not hold up. While unit tests are meant to be the backbone of your application testing, acceptance tests often give a more conclusive picture of the application as it usually exercises the whole stack. But keep in mind that unit tests are faster and acceptance tests are coming to be slower.
And this is the downside of acceptance tests. One of the reasons why they are on top of the pyramid is that they were more costly to run than the unit tests. As a unit test exercises a small piece of code, as seen before, they're incredibly fast to run. If you want to test the full user flow, like...
Let's say we want to sign up using a form. We want to navigate to the settings. We want to change the value for email and then sign out again. There's a lot of things we need to keep in mind and steps we need to run through.
It just needs way more resources to run. The database must probably be there. The browser needs to be simulated. The whole application must boot up accordingly and so on.
Those are all factors that drive up the cost of such a test. and the price we pay is actually time. While 100 unit tests might take only a couple seconds, 100 acceptance tests can take up to several minutes. That's the reason why we tend to say that acceptance tests are more costly.
We will keep this in mind when we start writing our tests. Before we dive deeper, we need to talk about some testing specific jargon, and we'll use it to introduce some fundamental tools in writing good tests. As mentioned in the previous video, you can test small pieces of code or follow complex user flows, and also everything in between. In the testing world, there are some broadly used terms to describe those pieces.
Testing small pieces are called unit tests. Testing more complex flows are often called or referred to as acceptance tests or end-to-end tests. And things in between often fall into the category of integration or functional tests. To make this lesson a little more practical, let's create a short unit test example from scratch.
Here we have the user. This is a simple user class that just gives us a constructor and we have a get parameter to call the name directly there. So how would we approach testing this class? So first of all, let's write the test directly in this file and we create a test function.
Okay, so we want this function to actually run and verify that the code is working. So the first thing we need is basically we need to create a new user to have some kind of data to verify what's going on. So let's create this new user. Okay, so we create a new user, we define the user details upfront, and then say, let's define the test user and we just create a new user instance using the user details that we just created.
Let's just verify that this one is actually working and giving us the correct name in return. We will do this with a simple console log function. So this is our console log function. In order to see that everything works as expected, we need to execute this test.
In this case, I just call it. Ideally, in this case, I'm going to use node to execute the test on the command line, but you can do this in any browser as well. Perfect. Here we see that our username is correct and printout true.
If I would change the name here and rerun the code, I would actually see that the username is no longer correct. So here we created a very simple test without any helper tools, but it verifies that the user class is actually working as intended. Besides this not being the most practical way of writing a test, it would give us insight into the user class working as expected. But let's proceed.
If you search for types of testing further, you might probably very soon stumble over the testing pyramid. It would look something like this. This is a very idealized concept of how many tests of which type should be in the system. In the real world, this often does not hold up.
While unit tests are meant to be the backbone of your application testing, acceptance tests often give a more conclusive picture of the application as it usually exercises the whole stack. But keep in mind that unit tests are faster and acceptance tests are coming to be slower. And this is the downside of acceptance tests. One of the reasons why they are on top of the pyramid is that they were more costly to run than the unit tests.
As a unit test exercises a small piece of code, as seen before, they're incredibly fast to run. If you want to test the full user flow, like... Let's say we want to sign up using a form. We want to navigate to the settings.
We want to change the value for email and then sign out again. There's a lot of things we need to keep in mind and steps we need to run through. It just needs way more resources to run. The database must probably be there.
The browser needs to be simulated. The whole application must boot up accordingly and so on. Those are all factors that drive up the cost of such a test. and the price we pay is actually time.
While 100 unit tests might take only a couple seconds, 100 acceptance tests can take up to several minutes. That's the reason why we tend to say that acceptance tests are more costly. We will keep this in mind when we start writing our tests. Before we dive deeper, we need to talk about some testing specific jargon, and we'll use it to introduce some fundamental tools in writing good tests.