Syntax for the name of the test file: {yui_module}.{affinity}-tests.js

For example, the name of the unit test YUI module for the HelloMojit mojit
with the server affinity would be HelloMojit.server-tests.js.

The unit test YUI module should include the target module and the mojito-test
module in the requires array. The requires array includes the mojito-test
module and the target module HelloMojit:

{requires:['mojito-test','HelloMojit']}

Note

Test files that are not in a tests directory may be found by
Mojito as long as the file name has the suffix -tests. The
suggested practice though is to place all test files in the tests
directories shown above.

You create unit tests for your mojits and execute them also using the mojito
command. Mojit tests must require (included in the YUI require array) the
module undergoing testing and the Mojito Test module mojito-test. For
example, if the Foo module was being tested, the requires array would
include the Foo and mojit-test modules as seen here:
requires:['Foo','mojit-test']

By default, Mojito uses the YUI Test
framework for the test harness
and assertion functions. Each mojit test will be executed within a YUI
instance along with its required dependencies, so you can be assured to only
have properly scoped values.

To use the Mojito test harness, you are required to name files and testing
modules according to certain rules. The name of the test file must have the
same affinity as the file being tested and
have the string -tests appended to the affinity. For example, the mojit
controller with the common affinity would be controller.common.js,
so the name of the test file must be controller.common-tests.js.

The controller.common.js below registers the Foo module.

YUI.add('Foo',function(Y){...});

To test the Foo, module, the the test file controller.common-tests.js would
require the Foo and ‘mojito-test’ modules as seen below.

A mojit can have one or more controllers that have different affinities. For each
controller, you can create create a test controller with the same affinity or use
controller.common-tests.js, which tests controllers with any affinity. For example,
controller.server.js can be tested with controller.server-tests.js or
controller.common-tests.js.

To test the controller of the Foo mojit, create a file in the tests
directory called controller.common-tests.js that includes the Foo-tests
module as seen below. Note that the reference to the controller is gotten
using Y.mojito.controllers[NAME].

The mojito-test YUI module allows you to create the mock object
MockActionContext to test without dependencies. Using the
MockActionContext object, you can easily build an ActionContext
for your controller, addon, and model tests. To learn more information
about using YUI to create mock objects, see
YUI Test Standalone Library: Mock Objects.

To test with the MockActionContext object, you use the expect method
and pass it an expectation object containing the properties method,
args, and run. These properties, in turn, contain the controller
method to test, the function parameters, and the test function.

In the code snippet below, the expect method creates a test for the
controller method done, using the YUITest module to perform an
assertion on the function’s return value.

Model tests are largely the same as controller tests, except there can be
many of them. The model tests are placed in the tests/models directory.
You can create multiple model tests or use models.common-tests.js to test
both server and client models.

Mojito allows you to use npmtest to run tests and also
comes with the script run.js that allows you to have more control over the test(s)
you want to run and where you want to write the test results.

Mojito uses the npm module Arrow, a testing framework
that fuses together JavaScript, Node.js, PhantomJS, and Selenium. By running the built-in
unit and functional tests, contributors can accelerate the merging of
their pull request.

Before making pull requests, we recommend contributors do the following:

To run tests in a browser, you need the Selenium Server
and browser drivers. Selenium Server comes with a driver for Firefox, so do not need to
install the Firefox driver. To run tests in Chrome and other browsers, you will need to
install the appropriate drivers. In the
steps below, we’ll just be using the default browser Firefox.

If you are not using Firefox v20 and the Selenium Standalone Server v2.31.0, you
may run into backward compatibility issues. Please see the
Platforms Supported by Selenium
to learn what Selenium and browser versions are compatible.

Change to the mojito/tests directory.

Start the Selenium server in the background.

$java-jarpath/to/selenium-server.jar&

Run the unit tests for the framework and client. As we mentioned before, the default
browser is Firefox. To specify Chrome, you would add the option --browserchrome.

$./run.jstest-u--pathunit--groupfw,client,server--reuseSession

You can also run all the functional tests with the below command.

$./run.jstest-f--pathfunc--port4000

The functional tests may take some time to complete, so you may want to
terminate the tests with Ctl-C. Also, you do not need to specify the port
with --port, but the command above does to show you the option.

To run individual unit and functional tests, you pass the test descriptor
to run.js.

The command above runs the functional test for the
newsboxes application. The --path option indicates that the
path to the test descriptor is located in the func directory: func/examples/newsboxes/newsboxes_descriptor.json

Test results are written in both XML and JSON. You can specify the location to write
test results or use the default location. In the following sections, we’ll look at the
default locations and the way to specify the location for unit and functional tests.