Wonderfully, when writing these tests the data is simply the markup in an HTML file. There are a few required parts when creating a test HTML file. As an example, take a look at the InlineEdit-test.html file.
- The inclusion of the test framework:
- The inclusion of the modules that will be tested:
- The inclusion of the tests and their supports:
- Markup that QUnit looks for when running the tests and displaying the test results:
- Markup that the tests use as data - everything inside the div with the id 'main'
- Wrap everything in a call to 'ready':
- Create a new test case:
- tests and add them to the test case:
- asynchronous tests and add them to the test case:
InlineEditTests.js uses the jqUnit API for its tests.
To run the tests, open up the HTML file in the browsers that you are testing. Failing tests will be red. Clicking on a failing test will show you the details of the test.
jQuery has a testing framework called QUnit http://docs.jquery.com/QUnit. Fluid uses a little wrapper for QUnit called jqUnit which allows us to write tests using a jUnit style API. The main difference between the QUnit and jqUnit are the names of the test functions and the order of parameters. In QUnit, the names are short and simple such as 'equals' and the order of parameters is "actual, expected, message". In jqUnit the names begin with assert such as 'assertEquals' and the order is "message, expected, actual". The wrapper was created (thanks Colin) because we had lots of jUnit style tests prior to using QUnit and we wanted to port them with the least amount of work. It's now up to each developer whether they want to use the QUnit API or the jqUnit API. People coming from a background of writing jUnit tests in java tend to prefer the jqUnit API simply because of habit and you will notice that most of the unit tests in Fluid use that format.