JS error prevents Jasmine run and coverage report about blanket

[alex-seville]

When code is instrumented in Blanket it's wrapped in a try-catch statement to automatically fail if the source code was somehow corrupted by the instrumentation process. I could add a flag so that the try-catch-ing can be disabled.

[provegard]

I see that you do blanketEval within the try-catch. I guess it's to run the script code as it would otherwise be run by the browser? I suppose the try-catch is ok, but perhaps the problem resides from the fact that context.completeLoad won't be called?

[provegard]

I moved the context.completeLoad call into a finally statement, and now I get the Jasmine run as well as a coverage report. However, the Jasmine tests are run twice.

[alex-seville]

I've created some code that does the same thing. It should be merged into master in a while.
As for why the tests are run twice, all I can think is that maybe the test harness is running the tests before the blanket jasmine adapter overrides it?

Is your Jasmine test runner similar to this?
https://github.com/Migrii/blanket/blob/master/test/jasmine/SpecRunner.html#L26

The blanket jasmine adapter, if loaded before the jasmineEnv.execute() is executed, will overload the references to execute so that it can only be run after all the scripts have been instrumented (https://github.com/Migrii/blanket/blob/master/test/jasmine/SpecRunner.html#L53).

[provegard]

Yes, the test runner is similar to what you linked to.

The double test execution happens when there is a data-cover attribute on the script file that contains the specs. If I remove it from instrumentation, the specs only execute once.

[alex-seville]

Ah, okay. The data-cover attribute is only needed for source files, not on spec/test files.

[alex-seville]

Additionally, you can use the data-cover-only attribute on the blanket script reference (only) to avoid having to add data-cover to each script.

The usage, to instrument files stored in a directory named "source", would be something like:
<script type="text/javascript" data-cover-only="source/" src="../../dist/qunit/blanket.min.js" data-cover-adapter="../../src/adapters/jasmine-blanket.js"></script>

[provegard]

Well, my use case is that I have one pattern for files to include in the instrumentation and one for files to exclude from instrumentation. The patterns are evaluated using the PathMatchSpec function in Windows. The test harness is generated, so it doesn't matter how I add the attributes. Frankly, adding data-cover on each script file that is eligible for instrumentation given the two patterns is extremely simple.

Now, if the user doesn't provide any patterns, all files will be instrumented, including the spec/test files. I know this is completely unnecessary, but I also think it shouldn't matter.

[provegard]

Changing the type attribute of the script tags with a data-cover attribute to text/blanket fixes the problem, as it prevents the browser from processing them.

[provegard]

About the try-catch and finally - you mentioned that you have some code that does the same thing. Any chance you could give a preview? If so, I can test it and see if it works for me.

[alex-seville]

I'm a little undecided whether it should matter in the grand scheme of things (the coverage output will be a list of files they aren't concerned with), but I can explain why instrumenting the test files causes them to execute twice.

When we instrument files we basically replace their references in the global scope by re-evaluating the instrumented code. However, I think with the Jasmine test specs duplicate tests are being added to the jasmine object, rather than being replaced. I don't know of a generic way of avoiding this, so the easier way is to just avoid instrumenting any of the test files.

[alex-seville]

"Changing the type attribute of the script tags with a data-cover attribute to text/blanket fixes the problem, as it prevents the browser from processing them."

Ah, that'll work as a workaround.

[alex-seville]

I'll commit it to my fork in a few minutes and add a link here.

[provegard]

Great, thanks!

[alex-seville]

Erg, having some issues. This is the gist of it though:

In blanketRequire I do this:

try{
_blanket.utils.blanketEval(instrumented);
context.completeLoad(moduleName);
}
catch(err){
if (_blanket.getIgnoreScriptError()){
//we can continue like normal if
//we're ignoring script errors,
//but otherwise we don't want
//to completeLoad or the error might be
//missed.
context.completeLoad(moduleName);
}else{
throw new Error("Error parsing instrumented code: "+err);
}
}

where getIgnoreScriptError returns a boolean set beforehand. I'm not sure if it helps with your situation though...

[provegard]

I think it does. The important thing for me is the completeLoad call. Will I be able to add an attribute to the Blanket script tag to control the ignore-errors flag?

[alex-seville]

Yes. You'll be able to add data-cover-ignore-errors attribute.

On Thu, Dec 27, 2012 at 7:04 PM, Per Rovegård [email protected]:

I think it does. The important thing for me is the completeLoad call.
Will I be able to add an attribute to the Blanket script tag to control
the ignore-errors flag?

—
Reply to this email directly or view it on GitHubhttps://github.com/Migrii/blanket/issues/142#issuecomment-11721820.

[provegard]

Any idea when you will push this and QUnit autostart support to master?

[alex-seville]

done Landed in https://github.com/Migrii/blanket/pull/145

[provegard]

Great! Will give it a try soon!

[alex-seville]

I created an example in test/ignore_script_error/runner.html also.

[provegard]

It works just fine, so let's close the issue (even if you're going to change the attributes).