Comments (22)
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.
from blanket.
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?
from blanket.
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.
from blanket.
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).
from blanket.
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.
from blanket.
Ah, okay. The data-cover
attribute is only needed for source files, not on spec/test files.
from blanket.
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>
from blanket.
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.
from blanket.
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.
from blanket.
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.
from blanket.
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.
from blanket.
"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.
from blanket.
I'll commit it to my fork in a few minutes and add a link here.
from blanket.
Great, thanks!
from blanket.
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...
from blanket.
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?
from blanket.
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.
from blanket.
Any idea when you will push this and QUnit autostart support to master?
from blanket.
done Landed in https://github.com/Migrii/blanket/pull/145
from blanket.
Great! Will give it a try soon!
from blanket.
I created an example in test/ignore_script_error/runner.html
also.
from blanket.
It works just fine, so let's close the issue (even if you're going to change the attributes).
from blanket.
Related Issues (20)
- Commented on: Not seeing any reports - noob alert #244 HOT 1
- _$jscoverage is not defined | blanket 1.2.1 HOT 21
- Reason for replacing ".js" with ""
- In ploymer,the script is written in the component html,is there any method to set data-cover on the script HOT 2
- Publish the latest version HOT 1
- Global object replaced on QUnit test
- How to use Blanket.js in test files loaded with Require.js? HOT 2
- blanket js does not given correct results.
- Can blanket handle source maps?
- documention is wrong for using with mocha HOT 1
- Advice on how to use with WebDriver. HOT 1
- Support for phantomjs 2.1.1 (for blanket to work on ppc64le architecture)
- Coverage for hoisted vars HOT 2
- I am getting Error: invalid reporter "html-cov" HOT 1
- Tests stop running on upgrading to [email protected] HOT 1
- make a new release on the github?
- Instrumentation affects test results.
- Running Jasmine Code Coverage using command Line
- Deprecate this?
- Hi
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blanket.