Menu
▾
▴
codecover-devel — Main mailing list of the CodeCover project.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rick K. <rmk...@gm...> - 2013-06-11 16:36:17
|
Hello CodeCover... I’m trying to understand the coverage we achieve during different portions of our testing and I’m looking for a ‘one-size-fits-all’ tool… Of these tools: JVM Monitor < http://www.jvmmonitor.org/doc/index.html > ß basically a profiling tool for performance eval, imho Cobertura < http://cobertura.sourceforge.net/ > ß ??? EMMA < http://emma.sourceforge.net/faq.html > ß ??? Clover < http://www.atlassian.com/software/clover/overview > ß measuring unit test code coverage in a dev environment is this tool’s bread & butter Sonar < http://www.sonarsource.org/ ß been recommended to avoid this one… How does CodeCover perform across differing testing regimes, i.e., unit, integration, acceptance etc…? ditto for CodeSurfer? & JAVALANCHE? Best, -r |
|
From: <F_C...@DE...> - 2011-12-29 14:24:35
|
Hi, my name is Fábio and i would like to know if you guys are still working on codecover. If you are working in some new released, bugfix or something. Thank you. Fabio Costa Silva Dell | Financial Services IT office +55 51 3274 0000 |
|
From: Conrad H. <cod...@xr...> - 2011-05-29 22:34:39
|
Hi there, Is the process for modifying the grammar and then rebuilding CodeCover with the new grammar documented anywhere? I've just submitted a patch to allow support default template array initializers in Java, but the process of creating it was a bit hairy because the grammar doesn't seem to generate the source files currently under trunk/code... Regards, Conrad |
|
From: 刘开玄 <liu...@gm...> - 2010-03-16 05:22:43
|
Hi All, How to make codecover work with "classpath:xxxx.xml" ? We have test case using a lot of resource files under the source-code folder (ehcache.xml, log4j.properties, xx.hbm.xml, properties etc.). Our normal TestCase is fine as Eclipse will copy it to the bin directory while compiling, but the codecover is unhappy with that. Anything located by "classpath://xxxx" goes wrong. so, is there a setting for me to choose what files should be copied ? Thanks in advance! |
|
From: <Tim...@in...> - 2010-01-28 16:23:44
|
Hallo, it is possible to use codecover with the eclipse rcp mechanism? i have my rcp plugins and this plugins have their test plugins, who testing the application code. it is possible to use codecover here? e.g. i want acitvate codecover for my testing plugins and test die application plugins. ____________________________________ Mit freundlichen Grüßen Timur Achmetow Software Engineer INDUSTRONIC GmbH & Co. KG Carl-Jacob-Kolb-Weg 1 97877 Wertheim / Germany fon: +49 (0)9342/871-240 fax: +49 (0)9342/871-17 mailto:tim...@in... http://www.industronic.com |
|
From: Jim S. <ji...@ji...> - 2009-08-09 02:50:16
|
I'm using Eclipse Java EE IDE for Web Developers, Build id: 20090621-0832. I installed using the instructions here: http://www.codecover.org/documentation/install.html The install reported no warnings or errors, and everything looks fine in Eclipse. It's just that when I try to run tests, it throws the error below. This is all the information in the log. What can I do to further debug this problem? !ENTRY org.eclipse.core.resources 4 2 2009-08-08 18:38:37.312 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 org.codecover.model.utils.FatalException: A fatal error occured: An error occured when trying to compile the instrumented sources. at org.codecover.model.utils.Logger.log(Logger.java:50) at org.codecover.model.utils.Logger.log(Logger.java:65) at org.codecover.model.utils.Logger.log(Logger.java:78) at org.codecover.model.utils.Logger.fatal(Logger.java:92) at org.codecover.eclipse.builder.CodeCoverCompilationParticipant.buildStarting(CodeCoverCompilationParticipant.java:355) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.notifyParticipants(AbstractImageBuilder.java:565) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:287) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:218) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:360) at org.eclipse.core.internal.resources.Project$1.run(Project.java:522) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1782) at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:502) at org.eclipse.core.internal.resources.Project.build(Project.java:94) at org.eclipse.debug.core.model.LaunchConfigurationDelegate$1.run(LaunchConfigurationDelegate.java:423) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1782) at org.eclipse.debug.core.model.LaunchConfigurationDelegate.buildProjects(LaunchConfigurationDelegate.java:430) at org.eclipse.debug.core.model.LaunchConfigurationDelegate.buildForLaunch(LaunchConfigurationDelegate.java:126) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:821) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:703) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:866) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1069) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) |
|
From: rob.h <ro...@gm...> - 2009-05-16 09:26:51
|
When building CodeCover with Eclipse 3.4.2, the following error is reported by the Eclipse compiler on the enum "Type" in class org.codecover.eclipse.views.CoverageView [1]. This is due to bug #263877 of Eclipse [2]. There is a patch for Eclipse 3.4 available, which just needs to be extracted in the "dropins" directory in your Eclipse installation directory [3], [4]. rob.h [1]: <http://codecover.svn.sourceforge.net/viewvc/codecover/trunk/code/eclipse/src/org/codecover/eclipse/views/CoverageView.java?revision=1&view=markup#l_1217> [2]: <https://bugs.eclipse.org/bugs/show_bug.cgi?id=263877> [3]: direct link to patch (unzip to the "dropins" directory of Eclipse) <http://www.eclipse.org/jdt/core/patches/patch.zip> [4]: homepage with Eclipse 3.4 updates <http://www.eclipse.org/jdt/core/r3.4/index.php#UPDATES> |
|
From: Jason A. T. L. <jas...@gm...> - 2009-03-23 04:34:50
|
On a fresh install of CodeCover using the updates site, I get the error below in my log as soon as I try to look at the Preferences Pane for CodeCover. MyEclipse 7.1 (Ganymede 3.4) % java -version java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) This is on an OS X 10.5.6 developer laptop. Anyone else experiencing same problem, or something similar? - Jason !ENTRY org.eclipse.jdt.core 4 2 2009-03-23 00:24:41.142 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jdt.core". !STACK 1 org.eclipse.core.runtime.CoreException: Plug-in org.codecover.eclipse was unable to load class org.codecover.eclipse.builder.CodeCoverCompilationParticipant. at org .eclipse .core .internal .registry .osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:180) at org .eclipse .core .internal .registry .osgi .RegistryStrategyOSGI .createExecutableExtension(RegistryStrategyOSGI.java:164) at org .eclipse .core .internal .registry .ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:867) at org .eclipse .core .internal .registry .ConfigurationElement .createExecutableExtension(ConfigurationElement.java:243) at org .eclipse .core .internal .registry .ConfigurationElementHandle .createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.jdt.internal.core.JavaModelManager $5.run(JavaModelManager.java:264) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.core.JavaModelManager $ CompilationParticipants .getCompilationParticipants(JavaModelManager.java:259) at org .eclipse .jdt .internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.java: 580) at org .eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java: 167) at org.eclipse.core.internal.events.BuildManager $2.run(BuildManager.java:633) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org .eclipse .core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org .eclipse .core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager $1.run(BuildManager.java:253) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org .eclipse .core.internal.events.BuildManager.basicBuild(BuildManager.java:256) at org .eclipse .core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java: 341) at org .eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java: 140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:675) at org .eclipse .osgi .internal .baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165) at org .eclipse .osgi .baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java: 554) at org .eclipse .osgi .baseadaptor .loader.ClasspathManager.findClassImpl(ClasspathManager.java:524) at org .eclipse .osgi .baseadaptor .loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455) at org .eclipse .osgi .baseadaptor .loader .ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java: 443) at org .eclipse .osgi .baseadaptor .loader.ClasspathManager.findLocalClass(ClasspathManager.java:423) at org .eclipse .osgi .internal .baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java: 193) at org .eclipse .osgi .framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java: 368) at org .eclipse .osgi .framework .internal.core.BundleLoader.findClassInternal(BundleLoader.java:444) at org .eclipse .osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java: 397) at org .eclipse .osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java: 385) at org .eclipse .osgi .internal .baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org .eclipse .osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java: 313) at org .eclipse .osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org .eclipse .osgi .framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java: 1274) at org .eclipse .core .internal .registry .osgi .RegistryStrategyOSGI .createExecutableExtension(RegistryStrategyOSGI.java:160) ... 20 more |
|
From: Tilmann S. <til...@go...> - 2009-02-07 10:13:53
|
Hi Thomas, On Tue, Feb 3, 2009 at 3:51 PM, Thomas Louis <lo...@ne...> wrote: > I just got linked to CodeCover on my search for an code coverage tool for > testing a big JEE application. > Despite it is a quite big application we just started to establish automated > testing routines. The biggest problem we have is to distinguish which parts > of the code should be tested. The application is very stable in it's current > release but with every update we are afraid of bringing in new bugs. Ok > It's > not possible to test everything before a new release goes productive. Because it would take too long to do all the manual tests? If so, CodeCover has some features (per-test coverage, correlation matrix) which allow you to optimize your manual test suite by giving you hints about test cases which are likely to be redundant. > So the following idea got into my mind. What if a code coverage tool can > state how much of my _changed_ code I got tested. The changed code can be > easily determined by an SVN difference (or other versioning systems). The > tests could be done automatically or manually. If doing them manually one > could see which code passages that where changed between two software > releases got coverd by testing and keep on testing until every change got > tested. > First I want to know what you think about that idea. Do you think that it is > a good idea to test only the differences between stable code and the new > code? In my opinion it definitely makes sense to focus on testing the areas where code changed, especially if the effort which you can spend on testing is limited. Note that code coverage in general only gives you hints about your test suite. If your code coverage is low this implies that your test suite is bad, since it doesn't even really touch the code to be tested. On the other hand, high code coverage does not necessarily imply that your test suite is good, it only shows one aspect of your test cases: which code they covered, it does not tell you anything about other aspects of the quality of your test suite e.g. the quality of the input data and the expected results of the individual test cases. > Do you think testing manually in combination with a code coverage tool > makes sense? Absolutely, CodeCover was designed with manual testing in mind. > Can you make any suggestions of how to integrate that into CodeCover? Basically two things are needed: (1) A mechanism to determine the pieces of code which changed, e.g. what diff does. It probably makes sense to reuse an existing tool/library for this. (2) A way to mark the pieces of code which should be covered and the functionality to use these marks. There is already support for adding meta information to the elements of the MAST (this is the data structure which contains the contents of a source file in a more abstract representation which is suitable for a coverage tool), so it should not be difficult to add a "this method should be covered" flag for methods which were identified by (1). Then maybe a different mode should be added, where the coverage is calculated relative to the marked methods/classes. I'm not sure how much work this is in total, I would assume (1) is the bigger part here, but I don't see any major technical difficulties in implementing such a feature. A contribution of such a feature would certainly be welcome :) > PS: Darf man hier auch auf Deutsch schreiben? Please stick to english as the list subscribers are from all over the world :) Greetings, Tilmann |
|
From: Thomas L. <lo...@ne...> - 2009-02-03 14:51:10
|
Hi, I just got linked to CodeCover on my search for an code coverage tool for testing a big JEE application. Despite it is a quite big application we just started to establish automated testing routines. The biggest problem we have is to distinguish which parts of the code should be tested. The application is very stable in it's current release but with every update we are afraid of bringing in new bugs. It's not possible to test everything before a new release goes productive. So the following idea got into my mind. What if a code coverage tool can state how much of my _changed_ code I got tested. The changed code can be easily determined by an SVN difference (or other versioning systems). The tests could be done automatically or manually. If doing them manually one could see which code passages that where changed between two software releases got coverd by testing and keep on testing until every change got tested. First I want to know what you think about that idea. Do you think that it is a good idea to test only the differences between stable code and the new code? Do you think testing manually in combination with a code coverage tool makes sense? Can you make any suggestions of how to integrate that into CodeCover? regards, Thomas PS: Darf man hier auch auf Deutsch schreiben? -- Thomas Louis netzprofis GmbH & Co. KG Joseph-von-Fraunhofer-Str. 29 44227 Dortmund fon: +49-231-399802-70 fax: +49-231-399802-69 cell: +49-178-3464000 callto://hergaty mailto:lo...@ne... USt-IdNr. DE225365236 Amtsgericht Dortmund HRA 16304, Komplementärin: Gleis & Louis Verwaltungsgesellschaft mbH Amtsgericht Dortmund HRB 20179, Geschäftsführer: Marcel Gleis & Thomas Louis |
|
From: Tilmann S. <til...@go...> - 2009-02-02 16:19:09
|
Hi Hamilton, On Mon, Feb 2, 2009 at 3:05 PM, Hamilton Gross <ha...@ha...> wrote: > I've just discovered CodeCover through a link on StackOverflow > [http://stackoverflow.com/questions/39329/what-is-your-favourite-code-coverage-tools-free-and-non-free] > and am intrigued... > > I'm surprised that noone has written a plugin for the C language - > especially as you have taken so much effort to document how to add new > languages. Is there any particular reason for this? Is there already > another tool which performs the equivalent as CodeCover for C? Basically the only reason is that no one has stepped up yet to add C support to CodeCover, there aren't really any technical difficulties which would prevent C support. I'm not aware of any free tool for C which allows you to collect "advanced" coverage metrics like MC/DC and which is currently maintained. E.g. there is GCT, but it is based on an ancient version of GCC. In my opinion it would make the most sense to reuse an existing compiler frontend in order to do the instrumentation of the C source, like GCT did with GCC. Clang (http://clang.llvm.org) would be perfectly suited for this purpose, it is an open source BSD-licensed C/C++/Objective-C frontend which is actively developed and designed as a library, so that it can be used for many different purposes. It already contains the necessary functionality to instrument source code. Greetings, Tilmann |
|
From: Hamilton G. <ha...@ha...> - 2009-02-02 14:26:06
|
Hi all, I've just discovered CodeCover through a link on StackOverflow [http://stackoverflow.com/questions/39329/what-is-your-favourite-code-coverage-tools-free-and-non-free] and am intrigued... I'm surprised that noone has written a plugin for the C language - especially as you have taken so much effort to document how to add new languages. Is there any particular reason for this? Is there already another tool which performs the equivalent as CodeCover for C? Look forward to hearing from you. Regards, Hamilton __________________________________________________________ Hamilton Gross || ha...@ha... || www.hamiltongross.de __________________________________________________________ |
|
From: Markus K. <mkn...@us...> - 2008-12-21 21:22:05
|
Hello!
First, CodeCover is a great tool, but a Maven plugin is a killer feature
to me. Writing a Maven plugin which simply wraps the Ant tasks shouldn't
be a problem, but there need to be a way to load CodeCover plugins
directly from a jar instead of just let CodeCover load the plugins from
a specified directory, so CodeCover plugins can be stored in a Maven
repository. How hard is it the add such a function?
Also, CodeCover needs to be deployed to a (public) Maven repository. I
suggest the following structure:
GroupId for Codecover: org.codecover
ArtifactIds: codecover-core, codecover-ant, codecover-junit
GroupId for Report Plugins: org.codecover.report
ArtifactIds: html, cvs
GroupId for Instrumentation Plugins: org.codecover.instrumentation
ArtifactIds: jdk15, cobol85
E.g. the directory structure in the repository for codecover-core would
look like this:
org/
codecover/
codecover-core/
0.1/
codecover-core-0.1.pom
codecover-core-0.1.jar
codecover-core-0.1-src.jar
codecover-core-0.1-javadoc.jar
The POM file describes meta data like groupId, artifactId, version,
packaging, licence, dependencies, etc.
Example:
http://mirrors.ibiblio.org/pub/mirrors/maven2/net/sourceforge/cobertura/cobertura/1.9/cobertura-1.9.pom
(Cobertura also uses Ant, so the POM doesn't contain much informations)
I could take care of the deployment to a maven repository, but first the
plugin issue needs to be solved...
Best regards,
Markus
|
|
From: Tatta, S. <st...@On...> - 2008-06-21 23:41:21
|
> Hi, > > First of all, I would like to thank you for creating a pretty sleek > and useful code coverage software. I really enjoyed using the eclipse > plug-in that you have provided for my applications. Job, Well Done!! > > I'm running Cactus Test Cases (Tomcat 5.5 being the server) from > eclipse and when doing so the code cover doesn't seem to output the > coverage information. I'm not having any problems when running > the plain JUNIT test cases. May be Code Cover is not able to find the > .Ser file. > > It will be great if you can guide me in the right direction. > > Thanks, > Sunder |
|
From: Javier C. <jav...@ho...> - 2008-02-19 15:15:51
|
Thanks! ----- Original Message ----- From: "Steffen Kieß" <s-...@we...> To: "Javier Camarero" <jav...@ho...> Cc: <cod...@li...> Sent: Tuesday, February 19, 2008 2:17 PM Subject: Re: [CodeCover-devel] JavaCC Files Hello, Am Dienstag, den 19.02.2008, 12:32 +0100 schrieb Javier Camarero: > Hi, > > I would like to use Codecover with different COBOL dialects. > I've seen that Codecover parser is generated with JavaCC, but the jj > file is not availables. How can I obtain it? I would like to modify it > to recognize my COBOL dialect. > you can find them at https://codecover.svn.sourceforge.net/svnroot/codecover/trunk/misc/instrumentation/parsers/cobol_85_plain/ Steffen |
|
From: Steffen K. <s-...@we...> - 2008-02-19 13:39:55
|
Hello, Am Dienstag, den 19.02.2008, 12:32 +0100 schrieb Javier Camarero: > Hi, > > I would like to use Codecover with different COBOL dialects. > I've seen that Codecover parser is generated with JavaCC, but the jj > file is not availables. How can I obtain it? I would like to modify it > to recognize my COBOL dialect. > you can find them at https://codecover.svn.sourceforge.net/svnroot/codecover/trunk/misc/instrumentation/parsers/cobol_85_plain/ Steffen |
|
From: Javier C. <jav...@ho...> - 2008-02-19 11:32:40
|
Hi, I would like to use Codecover with different COBOL dialects. I've seen that Codecover parser is generated with JavaCC, but the jj file is not availables. How can I obtain it? I would like to modify it to recognize my COBOL dialect. Thanks, |
1 message has been excluded from this view by a project administrator.
