Open GoogleCodeExporter opened 9 years ago
Original comment by toc...@gmail.com
on 21 Oct 2009 at 12:56
Issue 83 has been merged into this issue.
Original comment by corbinrs...@gmail.com
on 28 Oct 2010 at 12:13
This also covers the fact it looks like it takes into account the unit
tests/files themselves, which is also incorrect. The coverage should be for the
files under test.
Original comment by benmatse...@gmail.com
on 23 Nov 2010 at 11:29
+1 for being able to exclude the tests themselves from the coverage
Original comment by bensmawf...@googlemail.com
on 19 Jan 2011 at 1:12
+1, i think, it can be done easily if internal resources will be placed out of
.jar archive, and all required libraries for tests can be referenced in
Runnerquirks.html, for example.
Original comment by fdd...@gmail.com
on 1 Feb 2011 at 10:20
Original comment by corbinrs...@gmail.com
on 30 Mar 2011 at 10:49
+1, need this with app code using ExtJS
Original comment by dpatte...@gmail.com
on 8 Jul 2011 at 1:42
I'm able to avoid including libraries in the coverage results by listing the
library files in the "args" property of the plugin definition in the config
file. Here's an example:
plugin:
- name: "coverage"
jar: "src/test/resources/jsTestDriver/lib/coverage-1.3.2.jar"
module: "com.google.jstestdriver.coverage.CoverageModule"
args: "/Users/xyz/project/js-lib/closure/closure.js,/Users/xyz/project/js-lib/ext/4.0.4/builds/ext-all-sandbox-debug.js,/Users/xyz/project/js-lib/script.js,/Users/xyz/project/js-lib/calendar/calendar.js,/Users/xyz/project/js-lib/calendar/calendar-setup.js,/Users/xyz/project/js-lib/calendar/lang/calendar-en.js,/Users/mparrish/projects/alm/alm-webapp/src/test/slm.war/js-lib/sinon/sinon-1.1.1.js,/Users/mparrish/projects/alm/alm-webapp/src/test/slm.war/js-lib/jasmine/jasmine-1.0.2.js"
You can also add any file that is loaded (test files, prod files) that you want
excluded from the results. Note that the coverage plugin seems to want the full
filename to match and exclude properly.
Original comment by mparr...@rallydev.com
on 15 Aug 2011 at 10:14
+1, need to test javascript code using ExtJS
Original comment by white.sp...@googlemail.com
on 25 Nov 2011 at 12:12
+1. As mentioned in comment 8 there is a way to exclude specific file
locations. What's needed is support for wildcard characters, like the load and
test fields. As is everyone who works on a project will need to customize the
file for their specific folder structure.
Original comment by Kenneth....@gmail.com
on 24 Feb 2012 at 12:09
It looks to me like this is fixable in a backwards-compatible way by supplying
a CoveragePluginInitializer (implementing PluginInitializer). You'd reference
this in your config instead of CoverageModule, and it would be passed a copy of
the configuration - including BasePaths, so it can resolve relative paths etc.
The initializer then creates an instance of CoverageModule with the set of
/resolved/ paths, and the rest of the code is unchanged.
Yes I should just write this as a patch but it's taken me most of the evening
to get my head round Guice...maybe later this week.
Original comment by brian.ew...@gmail.com
on 22 Apr 2012 at 10:12
Ok here is a class that (partially) fixes the issue. To use this, add it to the
build and change this line in build.xml:
<attribute name="plugin-module"
value="com.google.jstestdriver.coverage.CoverageModule" />
with:
<attribute name="plugin-initializer"
value="com.google.jstestdriver.coverage.CoverageInitializer" />
Then you also need to run both client and server with --plugins
plugins/coverage.jar. This is because of an oddity in the plugin loading
mechanism; plugins loaded from the command line will have their plugin
initializers executed, plugins loaded via the config won't. I don't follow the
Guice config well enough to figure out why.
There's yet more wierdness in that if you decalare a plugin initializer (and
hence get access to the config) you won't get passed the args to the plugin
that PluginLoader knows about. So in the attached code, I have to work around
this by iterating over the config until I find the plugin that corresponds to
the current initializer.
The plugin mechanism makes very little sense to me - I suspect that that I got
this to work at all is a bug.
Original comment by brian.ew...@gmail.com
on 23 Apr 2012 at 11:02
Re-adding CoverageInitializer.java, the upload had picked up some unnecessary
debug statements.
Original comment by brian.ew...@gmail.com
on 23 Apr 2012 at 11:05
Attachments:
+1 Having relative paths for the exclusion files list (args) is very import
Original comment by c...@rocketmail.com
on 22 Jun 2012 at 6:59
How is about to provide an additional section in the configuration file
By extending the configuration with a optional "libs" section would be
backwards compatible.
libs:
- external-libs/ExtJS/src/main/ui/html/adapter/ext/ext-base.js
- external-libs/ExtJS/src/main/ui/html/ext-all.js
load:
- myfile.js
test:
- mytest.js
Original comment by daniel.k...@gmail.com
on 19 Jul 2012 at 11:47
I tried both relative and absolute paths in args for the libraries to exclude
from the coverage plugin and neither worked. The files seem to be ignored
every time I run JsTestDriver.jar with the coverage plugin in my config file.
Original comment by opara...@mail.gvsu.edu
on 26 Jul 2012 at 7:53
[deleted comment]
For all who have this problem, there's a solution here:
http://stackoverflow.com/questions/11887375/exclude-dependencies-from-js-test-dr
iver-code-coverage/13534598#13534598
Cheers
Original comment by edgarinv...@gmail.com
on 23 Nov 2012 at 7:59
Original issue reported on code.google.com by
karl.oke...@gmail.com
on 1 Oct 2009 at 9:01