MooTools ships with a copy of JSSpec and a suite of tests that validate much of the core functionality of the MooTools framework. The Clientcide libraries include tests for this suite that we use to validate our work (you can see those here).
These tests are great at determining tests that can be validated instantly by a computer. Does 2 + 2 = 4? If not, something is wrong. But they don’t do such a good job when the result is asynchronous (like with Ajax) or when the test requires user interaction (like dragging). Did the item fade in? Can you drag this? If you submit this form does the result load below? These kinds of tests don’t work in a test suite like JSSpec.
So I’m releasing the Clientcide Test Framework that does just this. It allows you to quickly author a test and any accompanying html that goes with it and then pose questions to the tester that they must answer yes or no to.
For example, let’s say we wanted to test our FormValidator class. The test file for it would look like this:
{
tests: [
{
title: "Form.Validator",
description: "Validates that a form's inputs are correct.",
verify: "Fill out the form as described and submit it. Were errors reported correctly?",
before: function(){
new FormValidator('foo', {
serial: false,
onFormValidate: function(passed, form, event){
event.stop();
if (passed) alert('form validated');
else alert('form did NOT validate');
}
});
}
}
]
}
Then we’d have an accompanying html file with a form it that would validate (I won’t paste it here).
This allows developers to write a quick test and develop code against it in a “clean” environment. The test framework has a “vanilla” iframe with almost no javascript in it by default (basically only a few methods used by the test framework). When the user loads a set of tests, the iframe loads the dependent scripts and then displays the tests for the user to run.
The other bit of useful integration is the script.json convention used in MooTools. Basically, in MooTools, there’s a file called scripts.json that lists each file in the library and it’s dependencies. This enables things like our downloads builder. The test framework uses this file to load the dependencies for a given test, and, in turn, the test allows you to verify that the scripts.json file is accurate and that the correct dependencies are being loaded.
Thought the test framework is written in MooTools (1.2.1), the test environment itself is completely vanilla. Other than the scripts.json convention, which anyone can use, it is not specific to MooTools in any way.
The suite is entirely authored in JavaScript, which means that it can be deployed anywhere, allowing you to write tests that interact with back-end server-side code. It can also be run from the deskt
The framework comes with an example set of scripts and tests for those scripts. These don’t use MooTools at all. You can read more about how to use the framework on it’s readme page and see the tests in action on the tests pages.
You can see Clientcide’s tests as well, which are a better indication of how the framework might be used.
The framework is available for download via Googl’es svn services:
http://code.google.com/p/clientside-test-framework
