Mox are a common tool when writing tests. Let's look at this piece of code. We import permissions from somewhere, we have a class user like before, we create a new user, and then we have the isUserAdmin function, what calls permissions. If we want to test the isUserAdmin function, it becomes clear we would actually test the permissions object.
For the function isUserAdmin, permissions is code from the outside of our file. All we know is that our class wants to use it. So it's depending on it to be there. That's why code pulled in from the outside gets often referred to as a dependency.
In this case though, if we want to test, our function calls the corresponding dependency accordingly. We need to replace permissions with something we can control in our test file. The process of replacing is often called mocking, and therefore the end result is called a mock. It could be described as an imitation or a dummy clone of the reference dependency.
In the context of our test, we actually do not care for how permissions work under the hood. We just care for it being called correctly. So let's try something out. In the previous lesson, we saw a brief example of how to run a test.
Let's try now to run a test that runs a mocked version of permissions. Forgive me, this is all happening in the same file. In the real world, you would probably structure it in different files. But in this case, I just want to demonstrate some things.
So first of all, let's try to create a mocked version of permissions. All we know now is that permissions has a granted function that gets called. So let's try to mock it now. So what's happening here?
We created a new permissions object. It has a granted function. And we see there are some parameters passed along. So we take those parameters.
and we push it to our own array that we can control. So that's why I ended up creating an args array for us as well that we can then take to verify the code is actually called correctly and keep track of all the parameters outside. Next, let's create our test function that would actually run the code. So as before, we here have our test function.
So we might want to call it. In this case, I do not want to put a console log into my test function. So we'll wrap the test call into a console log instead. Great.
So now we need something to actually log out. So we're going to return this directly from our test function. Okay. So what I try to do here is call a JSON stringify on our arguments array.
And we take the first instance because we know it's there. And also then we do a JSON stringify on a custom array that just represents the user and the admin that we have referenced here. Let's run our test quickly. We get a true in return, so those arguments seem to match and we know that permissionsGranted was called accordingly.
So as a result, we have imitated the permissions object and have our very own mocked version of it. We can now verify that permissionsGranted was actually called as args got filled with the correct parameters. So if we talk of a mock, we mean an alternate implementation of a dependency when we're testing our code. Mox are a common tool when writing tests.
Let's look at this piece of code. We import permissions from somewhere, we have a class user like before, we create a new user, and then we have the isUserAdmin function, what calls permissions. If we want to test the isUserAdmin function, it becomes clear we would actually test the permissions object. For the function isUserAdmin, permissions is code from the outside of our file.
All we know is that our class wants to use it. So it's depending on it to be there. That's why code pulled in from the outside gets often referred to as a dependency. In this case though, if we want to test, our function calls the corresponding dependency accordingly.
We need to replace permissions with something we can control in our test file. The process of replacing is often called mocking, and therefore the end result is called a mock. It could be described as an imitation or a dummy clone of the reference dependency. In the context of our test, we actually do not care for how permissions work under the hood.
We just care for it being called correctly. So let's try something out. In the previous lesson, we saw a brief example of how to run a test. Let's try now to run a test that runs a mocked version of permissions.
Forgive me, this is all happening in the same file. In the real world, you would probably structure it in different files. But in this case, I just want to demonstrate some things. So first of all, let's try to create a mocked version of permissions.
All we know now is that permissions has a granted function that gets called. So let's try to mock it now. So what's happening here? We created a new permissions object.
It has a granted function. And we see there are some parameters passed along. So we take those parameters. and we push it to our own array that we can control.
So that's why I ended up creating an args array for us as well that we can then take to verify the code is actually called correctly and keep track of all the parameters outside. Next, let's create our test function that would actually run the code. So as before, we here have our test function. So we might want to call it.
In this case, I do not want to put a console log into my test function. So we'll wrap the test call into a console log instead. Great. So now we need something to actually log out.
So we're going to return this directly from our test function. Okay. So what I try to do here is call a JSON stringify on our arguments array. And we take the first instance because we know it's there.
And also then we do a JSON stringify on a custom array that just represents the user and the admin that we have referenced here. Let's run our test quickly. We get a true in return, so those arguments seem to match and we know that permissionsGranted was called accordingly. So as a result, we have imitated the permissions object and have our very own mocked version of it.
We can now verify that permissionsGranted was actually called as args got filled with the correct parameters. So if we talk of a mock, we mean an alternate implementation of a dependency when we're testing our code.