When should a Teaspoon test be written?

The platform's JavaScript modules are written using The Revealing Module Pattern. If a module publicly exposes a method that method then becomes testable. The majority of the platform's modules, however, initialize only when an element with a specific selector is found within a given scope. These modules provide functionality for general use or for a specific feature are less straight forward to test.

Utility Modules

If a module is written with many useful public methods it becomes an ideal Teaspoon test candidate. An example of this is the WORKAREA.dialog module. This module is written to be almost entirely public facing, deferring a lot of the interactive functionality to other modules who make use of its API.

General Purpose Modules

If a general-use, DOM-based module is written then a fixture can be used as the method's scope. This way you are able to assert that the module functions properly within the vacuum that is the fixture. An example of this type of module would be the WORKAREA.dialogButtons module, which searches a given scope for an element with a data-dialog-button attribute before providing its functionality to said element.

Broken Code

If a JavaScript bug is uncovered during QA, a Teaspoon test should be written to prove that the bug exists before the code is updated. This ensures that the bug has actually been fixed and will not resurface again.

Feature Tests v. Unit Tests

For complex features, such as the content editing feature of the Admin, there is a large amount of JavaScript required to make the feature function properly. When writing Teaspoon tests for these types of modules keep in mind that you aren't using Teaspoon to test the feature itself, but how the methods provided by the module interact with the page.

It should be noted that feature tests require that the entire application be spun up each time the suite is run, so they should only be written to describe and verify high-level features. Unit tests do not require the entire application and are therefore much quicker. If you can provide adequate test coverage using unit tests, you should do so.

As you can see, the WORKAREA.string module has two public methods, titleize and pluralize. Each one of these methods function as a utility for other modules to use and, therefore, should be tested to ensure they are working properly:

Notice that there are no tests asserting that jQuery Tooltipster itself is working properly. Since the platform depends on this 3rd party plugin, and the plugin ships with it's own tests, we simply need to ensure that jQuery Tooltipster is being instantiated under the right conditions.