Wilgnner / js-test-driver

Automatically exported from code.google.com/p/js-test-driver
0 stars 0 forks source link

No way to exclude library code from the coverage plugin #42

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

* If you require a Javascript library for your code (e.g. jquery)
* When you use the coverage plugin
* It calculates code coverage for the library
* But there are no tests for the library, and never will be

* We should be able to exclude files from the coverage plugin

What is the expected output? What do you see instead?

I would expect to see only coverage for those files I write.

What version of the product are you using? On what operating system?

Using coverage-1.1.jar

Original issue reported on code.google.com by karl.oke...@gmail.com on 1 Oct 2009 at 9:01

GoogleCodeExporter commented 8 years ago

Original comment by toc...@gmail.com on 21 Oct 2009 at 12:56

GoogleCodeExporter commented 8 years ago
Issue 83 has been merged into this issue.

Original comment by corbinrs...@gmail.com on 28 Oct 2010 at 12:13

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
+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

GoogleCodeExporter commented 8 years ago
+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

GoogleCodeExporter commented 8 years ago

Original comment by corbinrs...@gmail.com on 30 Mar 2011 at 10:49

GoogleCodeExporter commented 8 years ago
+1, need this with app code using ExtJS

Original comment by dpatte...@gmail.com on 8 Jul 2011 at 1:42

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
+1, need to test javascript code  using ExtJS

Original comment by white.sp...@googlemail.com on 25 Nov 2011 at 12:12

GoogleCodeExporter commented 8 years ago
+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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
+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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
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