Modules and behaviors are so similar that they can be tested in the same ways. For every module testing example on this page, the same process can be used to test behaviors. You’ll use getModuleForTest() to retrieve a module instance for testing and getBehaviorForTest() to retrieve a behavior instance for testing. Outside of this difference, everything else is exactly the same for testing modules and behaviors.
For both modules and behaviors, you’ll want to double-check whether or not to call init() and destroy() after each test. The examples in this guide assume each module has both init() and destroy().
Modules with No Dependencies
If you’re writing a simple module that has no dependencies on other components or the context object, then you can use the following basic formats for your tests.
Create a new QUnit.module and give it the same name as your module (note that QUnit.module has nothing to do with T3 module). In the beforeEach() method, call getModuleForTest() to retrieve a reference to the module object and store it in this.module. Then, you can write as many tests as you want referencing methods on the this.module. Here’s a simple example:
For Mocha testing, create a describe with the name of your module. In the beforeEach() function, call getModuleForTest() to retrieve a reference to the module object. For each method you want to test, include another describe section, and then however many it tests you need to cover the functionality. For example:
Testing with Context Object and Services
If your module depends on the context object to perform its tasks, then you’ll need to stub it out. To do so, create a new instance of Box.TestServiceProvider, which is provided in the testing bundle. This object allows you to specify stub services for use in your test. These examples use Sinon as a stubbing library.
Assume you have a module defined as:
Writing a test for this module is fairly straightforward. The first thing to do is create a service stub called anotherService that has the methods you want the module to call. Then, a Box.TestServiceProvider is created an initialized with anotherService. This becomes a fake version of the context object that is normally passed into a module. That fake context is then passed to getModuleForTest() so the module can get access to it.
Testing Event Handlers
When you want to test how an event handler works, call the method directly on the module object and pass in an event object as the argument. You should fill in only the event properties that you are using within the event handler. For instance, suppose you have this module:
In this case, you want to test onclick() to see that when an element with the class name of "menu-btn" is clicked, the method showMenu() is called. You would not, however, want to test exactly what showMenu() is doing (that should be in a separate test where showMenu() is called directly). For the event handler, you simply want to test that the method was called as a result of the element that was clicked. To do so, you can use a Sinon mock on the showMenu() method to verify that it was called.
Testing with Configuration Data
If your module uses configuration data, then you must also stub out the getConfig() method for tests. Be sure to include all configuration keys your module needs.