kevee/quail — pull request #139 by jessebeach (2014-02-03 02:57:13+00:00)
Title: Introduce a layer of test result reporting that can provide feedback on ...

#101

These changes introduce a layer of processing on top of ```quail.testFails()```. The change is meant to be backwards compatible with existing calls to testFails, that is now a deprecated function which simply delegates to ```_processTestResult()```.

We now have three callbacks:

```javascript
quail.options.testNotApplicable()
quail.options.testFailed()
quail.options.testPassed()
```

I also introduced a new helper function for QUnit test confirmation

```javascript
/**
* Compares the status of the test result to the resultType argument.
*
* @param string resultType
* Possible values include: 'na', 'fail', 'pass'
* @return boolean
*/
confirmStatus: function (resultType) {
return quailTest.results[quailTest.testName].status === 'pass';
},
```

I'm not sure yet if this is the right approach. But it's a decent first step to introducing the concept of a 'passed' test.

The array ```quail.accessibilityResults[testName].elements``` still contains only the failed test elements. I haven't gotten to updating it yet.

The bigger question is, do we want all of these individual callbacks or would we rather have a single 'complete' callback that receives a dense data object with passes, fails, na's and such that the invoking program would need to parse. I tend more towards simply relying on a complete callback, but I'd like to get your opinion since I still don't have a good sense of how others have been using Quail up to now.

Signed-off-by: J. Renée Beach