4.1 Testing AMD Modules
Does using AMD modules have an impact on testing? Not at all—in fact it can help keep our tests as organised as our application files. In this lesson we’ll see how we can easily test our modules using the popular Jasmine test framework.
1.Introduction2 lessons, 06:55
2.RequireJS Basics4 lessons, 27:18
3.Handling Common Tasks5 lessons, 51:21
4.Advanced4 lessons, 22:08
5.Conclusion1 lesson, 02:59
4.1 Testing AMD Modules
Hi. In this lesson, we're going to see how we can make use of RequireJS for our unit tests. Not only can we test our AMD modules extremely easily. We can also write our unit tests as modules themselves. Replicating the organization of our src directory. We'll be running Require from the spec runner page. So let's get that set up first of all. [BLANK_AUDIO] First of all, let's link to the required source file and specify the main script. [BLANK_AUDIO] The default spec runner loads, several Jasmine scripts in the traditional way. Jasmine.js, jasmine-html.js, and boot.js. We don't want to load these like this. We want to use Require to load them. We can remove all three of these script files. We're going to need to do some configuration to get everything to work nicely. But as this is just configuration for the tests, which aren't going to get build into the package we deploy. We can just provide the configuration in line. So, let's start out with the following scripts. Which we can add before the script, for Require that we just added. [BLANK_AUDIO] So first of all, we'll want to set the baseURL back to the src directory. At this point, it's gonna be in the test folder. [BLANK_AUDIO] So we need to do this so that the modules that we're testing can load their dependencies correctly. We can also set a path to the spec folder so that we can load test easily without specifying a long path. [BLANK_AUDIO] We can also add paths for the three jasmine files that we removed from this page. [BLANK_AUDIO] We also need to add some shim configurations for some of the non-AMD jasmine files. [BLANK_AUDIO] Jasmine itself is compatible with Require and calls the define method if it exists. The jasmine-html and boot files however, don't. So we need to shim them. We set the dependencies and exports values and that's what we need to do. So now, we can add the main scripts that will boot strap the tests and get the test environment up and running. Let's create a new script file in the test folder and call it main.js. [BLANK_AUDIO] Inside this, we can add the following code. [BLANK_AUDIO] It starts out with a define method. Create an array of the spec files that we want to load. And then requires the boot file, which is what sets up the environment. We can then load the specs with another nested require method. And inside the callback for this, we can invoke the windows unload method for jasmine. So let's say we want to test the task manager module. We can create a new module in the spec folder and call it taskmanager.js. [BLANK_AUDIO] The spec folder can be organized in the same way as the main src folder that we're testing. And all of the test modules can have the same names as the modules they're testing. So the test folder will seem nice and familiar, and we'll want to visit it often. [BLANK_AUDIO] So at this point, it's looking pretty much how any other module would look to being with. We're going to want to load the module that we're testing as a dependency. Now we can write a basic test for the task manager module [BLANK_AUDIO] So we have a simple test that just asserts a couple of the task object properties. Now all we need to do is add the name of the spec to the specs array in our main script. [BLANK_AUDIO] So we should now be able to run the spec runner page in a browser and see our passing tests. [BLANK_AUDIO] So the test is failing, let's see why. And the test task itself doesn't have a task manager property. We want to use the task manager that gets passed into the module. And the test task needs to equal what gets returned. So now our tests are passing. So one useful test specific thing that require helps with in testing, is using mocks. The task manager that we just tested only has a dependency on the task constructor, which itself is pretty simple. If it was more complex and contained lots of additional functionality, we'd probably want to mock it when testing the task manager. After all, the task module itself should have it's own set of tests. The problem that we have to overcome is that when we load the task manager module in order to test it. The task manager module itself loads the task module. What we need to do is to create a path in the config so when the task manager requests the task, we can give it the mock instead. So in the test folder, let's add a new folder called mocks. And let's copy over the actual task module into the mocks folder for simplicity. And just so that we can verify that it's the mock loading and not the actual module, lets just add a simple console.log. Great. So now let's add a new path to our test config. And let's go back to the spec runner page now. And we'll refresh the page. And if we open up the console, we can see there is definitely the mock that's been loaded. So in this lesson, we learned how using RequireJS can really help us to make the most of our test infrastructure. We saw that we can write our tests themselves as AMD modules, which makes it very easy to load dependencies for the tests. We also saw that it's very easy to create a configuration that lets us load mocks from the modules that we're testing. In order to ensure that we're only testing a particular module. Thanks for watching.