jlgrock / ClosureJavascriptFramework

A group of plug-ins that can be used in conjunction with maven to execute the Google Closure Compiler on JavaScript code. This Framework allows for scaling and modularity.
MIT License
16 stars 7 forks source link

Issues parsing test results based on goog.testing.ContinuationTestCase #41

Open lukas-vlcek opened 10 years ago

lukas-vlcek commented 10 years ago

The goog.testing.ContinuationTestCase can be used for testing of async components. The problem, however, is that tests based on ContinuationTestCase do not output DIV element that can be parsed into TestCaseStart.

Check for example output of <closure-library>/closure/goog/testing/continuationtestcase_test.html.

As a result the test always end up with the following error:

[ERROR] (ClosureTestingMojo.java:85)
There was a problem with the '_path_to_test.html' Test Case.
Unable to scrape the results of any test cases.  Please check the output to guarantee that test cases are being executed or remove the test case file.

As of writing I am not sure what would be the best solution for this problem but I want to record it.

lukas-vlcek commented 10 years ago

It seems that one quick workaround might be the following:

goog.require('goog.testing.ContinuationTestCase');
goog.require('goog.testing.jsunit');

// standard beginning of the test, taken from continuationtestcase.js JSDoc example
var testCase = new goog.testing.ContinuationTestCase('Continuation Test Case');
testCase.autoDiscoverTests();
if (typeof G_testRunner != 'undefined') {
    G_testRunner.initialize(testCase);
}

// now comes the hack!!!
function shouldRunTests() {
    testCase.saveMessage('Start');    // <-- this line prints the Start message
    return true;    // <-- needed to make the tests run
}

// your standard tests follow...
lukas-vlcek commented 10 years ago

May be as a solution we could add new configuration parameter to AbstractClosureTestingMojo that would relax strict requirement for present "Start" DIV. What do you think @jlgrock

lukas-vlcek commented 10 years ago

It seems that it is recommended to use goog.testing.AsyncTestCase instead of goog.testing.ContinuationTestCase. See discussion here: https://groups.google.com/d/msg/closure-library-discuss/SB8Vnqc1DqQ/vt2U3LSvgHUJ

I will check AsyncTestCase and close this ticket if it can support all I need.

jlgrock commented 10 years ago

Sorry on the slow response to this, but I had to dig into old code to find this. Async stuff is a problem for this test case runner. We were running into it when testing Deferreds. Turns out, this wasn't tested so great in the Closure stuff either, so we had no idea what to do.

What we did add was a feature to inject code at the beginning. I guess if it was a Async test case, they suggested using the async testing only and the proper way to do this is not to do this in the javascript but to put it into the header itself, which causes more problems.

The solution for us was to adjust the `

com.github.jlgrock.javascript-framework
            <artifactId>closure-testing-maven-plugin</artifactId>
            <version>${jsframework.version}</version>
            <configuration>
                <prologue><![CDATA[
    <script>
        goog.require("goog.testing.jsunit");
        goog.require("goog.testing.AsyncTestCase");
                ...
    </script>
                ]]></prologue>`

And since this breaks non-async code, we had to put these test cases in a separate subproject. Annoying as hell.

I'm hoping this helps...