Menu
▾
▴
cobertura-featurerequests — Automated emails from our feature request tracking system
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(4) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(5) |
May
(1) |
Jun
(3) |
Jul
(7) |
Aug
(4) |
Sep
|
Oct
|
Nov
(6) |
Dec
(7) |
| 2009 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(16) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(7) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(2) |
| 2013 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2007-10-17 17:15:36
|
Feature Requests item #1815191, was opened at 2007-10-17 10:53 Message generated for change (Comment added) made by lewijw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1815191&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jeff MAURY (jeffmaury) >Assigned to: John Lewis (lewijw) Summary: Cobertura should support JAR, WAR, RAR and EAR files Initial Comment: It would be nice if Cobertura should be able to work on JAR, WAR, ... files instead of only directories of classes. It would allow a better use and integration (Maven and Cargo for example) ---------------------------------------------------------------------- >Comment By: John Lewis (lewijw) Date: 2007-10-17 11:56 Message: Logged In: YES user_id=1031161 Originator: NO This is already possible. Do something like this: <cobertura-instrument datafile="${basedir}/cobertura.ser" todir="${instrumented.dir}"> <includeClasses regex="test.*" /> <excludeClasses regex="test.*.B" /> <excludeClasses regex=".*Test*" /> <fileset dir="${tmp.dir}"> <include name="app.war" /> </fileset> </cobertura-instrument> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1815191&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-10-17 15:53:49
|
Feature Requests item #1815191, was opened at 2007-10-17 17:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1815191&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeff MAURY (jeffmaury) Assigned to: Nobody/Anonymous (nobody) Summary: Cobertura should support JAR, WAR, RAR and EAR files Initial Comment: It would be nice if Cobertura should be able to work on JAR, WAR, ... files instead of only directories of classes. It would allow a better use and integration (Maven and Cargo for example) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1815191&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-09-13 05:36:30
|
Feature Requests item #1443252, was opened at 2006-03-05 00:02 Message generated for change (Comment added) made by jirimares You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: jalbert (jalbert631) Assigned to: Nobody/Anonymous (nobody) Summary: Mark untestable code Initial Comment: I would like to be able to mark small pieces of "untestable" code (e.g. "catch" clauses for exceptions that cannot be readily simulated), and have it marked differently in the reports. I would like to be able to mark code in some way. I would suggest a comment flag at the start of each line - say "/*--*/" (probably it should be configurable). If a piece of unexecuted code is marked, it would be flagged in the source listings in yellow, rather than red, and the summary reports would show the percentage of "untestable" code in yellow, in addition to the current red and green bars. The reason is that I cannot readily tell, when looking at the reports, whether a lower-than-wanted percentage of testing is because there is code that should be tested but isn't, or code that cannot be tested. At present, I can't tell it a few lines have been added without testing, or it is still just the knowingly-untested code that is being reported. If, in a report, the green and yellow add up to 100%, I know there is no accidentally untested code. The marks I am suggesting would look a little ugly, but as far as I am concerned, that is fine - it is nothing something to be encouraged. This idea could be extended in many ways - e.g. mark "code I will test later", etc. - but I don't seen any need to get carried away. ---------------------------------------------------------------------- >Comment By: Jiri Mares (jirimares) Date: 2007-09-13 07:36 Message: Logged In: YES user_id=819956 Originator: NO We have been speaking about something like you are describing and the semi-decision we made was to reuse the clover comments, maybe to introduce some cobertura's one. So we know about this problem and want to solve it. ---------------------------------------------------------------------- Comment By: jalbert (jalbert631) Date: 2007-09-12 14:51 Message: Logged In: YES user_id=1467776 Originator: YES The problem is that there are pieces of code that are difficult or impossible to test in unit test. A typical example, as I mentioned in my original post, is the catch clause for an exception that cannot easily be simulated, such as a library that triggers an exception for a hardware problem, or an invalid data condition that cannot be established. Another example is code that is required but never intended to be executed, such as a private constructor for a static class. In some development methodologies, "trivial" methods, such as getters and setters, are not required to be tested. Even though trivial, or generated automatically by IDEs, they can form many lines of code in some classes, and result in Cobertura reporting very low levels of coverage - low enough that it is questionable whether the reports really have any value. (I do not support this approach, and have written a JUnit extension to automatically test most getters and setters, to eliminate this issue, but I have worked in places where this was the case.) ---------------------------------------------------------------------- Comment By: Kasper B. Graversen (kbg) Date: 2007-09-12 06:48 Message: Logged In: YES user_id=118125 Originator: NO Why are you not interested in testing your error handling code? or testing that your units actually handless erroneous situations? ---------------------------------------------------------------------- Comment By: hasko (hasko) Date: 2007-01-11 13:43 Message: Logged In: YES user_id=99663 Originator: NO It would also be nice to mark boilerplate code (e.g. toString) as not to be tested. As an additional idea: the markup could be based on annotations... ---------------------------------------------------------------------- Comment By: Bas Cancrinus (bascan) Date: 2006-05-22 16:08 Message: Logged In: YES user_id=437864 This would be a great solution to suppress coverage markers on private constructors. They are usually used only to avoid instantiation of utility classes, so they aren't covered by definition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-09-12 12:51:38
|
Feature Requests item #1443252, was opened at 2006-03-04 18:02 Message generated for change (Comment added) made by jalbert631 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: jalbert (jalbert631) Assigned to: Nobody/Anonymous (nobody) Summary: Mark untestable code Initial Comment: I would like to be able to mark small pieces of "untestable" code (e.g. "catch" clauses for exceptions that cannot be readily simulated), and have it marked differently in the reports. I would like to be able to mark code in some way. I would suggest a comment flag at the start of each line - say "/*--*/" (probably it should be configurable). If a piece of unexecuted code is marked, it would be flagged in the source listings in yellow, rather than red, and the summary reports would show the percentage of "untestable" code in yellow, in addition to the current red and green bars. The reason is that I cannot readily tell, when looking at the reports, whether a lower-than-wanted percentage of testing is because there is code that should be tested but isn't, or code that cannot be tested. At present, I can't tell it a few lines have been added without testing, or it is still just the knowingly-untested code that is being reported. If, in a report, the green and yellow add up to 100%, I know there is no accidentally untested code. The marks I am suggesting would look a little ugly, but as far as I am concerned, that is fine - it is nothing something to be encouraged. This idea could be extended in many ways - e.g. mark "code I will test later", etc. - but I don't seen any need to get carried away. ---------------------------------------------------------------------- >Comment By: jalbert (jalbert631) Date: 2007-09-12 08:51 Message: Logged In: YES user_id=1467776 Originator: YES The problem is that there are pieces of code that are difficult or impossible to test in unit test. A typical example, as I mentioned in my original post, is the catch clause for an exception that cannot easily be simulated, such as a library that triggers an exception for a hardware problem, or an invalid data condition that cannot be established. Another example is code that is required but never intended to be executed, such as a private constructor for a static class. In some development methodologies, "trivial" methods, such as getters and setters, are not required to be tested. Even though trivial, or generated automatically by IDEs, they can form many lines of code in some classes, and result in Cobertura reporting very low levels of coverage - low enough that it is questionable whether the reports really have any value. (I do not support this approach, and have written a JUnit extension to automatically test most getters and setters, to eliminate this issue, but I have worked in places where this was the case.) ---------------------------------------------------------------------- Comment By: Kasper B. Graversen (kbg) Date: 2007-09-12 00:48 Message: Logged In: YES user_id=118125 Originator: NO Why are you not interested in testing your error handling code? or testing that your units actually handless erroneous situations? ---------------------------------------------------------------------- Comment By: hasko (hasko) Date: 2007-01-11 07:43 Message: Logged In: YES user_id=99663 Originator: NO It would also be nice to mark boilerplate code (e.g. toString) as not to be tested. As an additional idea: the markup could be based on annotations... ---------------------------------------------------------------------- Comment By: Bas Cancrinus (bascan) Date: 2006-05-22 10:08 Message: Logged In: YES user_id=437864 This would be a great solution to suppress coverage markers on private constructors. They are usually used only to avoid instantiation of utility classes, so they aren't covered by definition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-09-12 04:48:29
|
Feature Requests item #1443252, was opened at 2006-03-05 00:02 Message generated for change (Comment added) made by kbg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: jalbert (jalbert631) Assigned to: Nobody/Anonymous (nobody) Summary: Mark untestable code Initial Comment: I would like to be able to mark small pieces of "untestable" code (e.g. "catch" clauses for exceptions that cannot be readily simulated), and have it marked differently in the reports. I would like to be able to mark code in some way. I would suggest a comment flag at the start of each line - say "/*--*/" (probably it should be configurable). If a piece of unexecuted code is marked, it would be flagged in the source listings in yellow, rather than red, and the summary reports would show the percentage of "untestable" code in yellow, in addition to the current red and green bars. The reason is that I cannot readily tell, when looking at the reports, whether a lower-than-wanted percentage of testing is because there is code that should be tested but isn't, or code that cannot be tested. At present, I can't tell it a few lines have been added without testing, or it is still just the knowingly-untested code that is being reported. If, in a report, the green and yellow add up to 100%, I know there is no accidentally untested code. The marks I am suggesting would look a little ugly, but as far as I am concerned, that is fine - it is nothing something to be encouraged. This idea could be extended in many ways - e.g. mark "code I will test later", etc. - but I don't seen any need to get carried away. ---------------------------------------------------------------------- Comment By: Kasper B. Graversen (kbg) Date: 2007-09-12 06:48 Message: Logged In: YES user_id=118125 Originator: NO Why are you not interested in testing your error handling code? or testing that your units actually handless erroneous situations? ---------------------------------------------------------------------- Comment By: hasko (hasko) Date: 2007-01-11 13:43 Message: Logged In: YES user_id=99663 Originator: NO It would also be nice to mark boilerplate code (e.g. toString) as not to be tested. As an additional idea: the markup could be based on annotations... ---------------------------------------------------------------------- Comment By: Bas Cancrinus (bascan) Date: 2006-05-22 16:08 Message: Logged In: YES user_id=437864 This would be a great solution to suppress coverage markers on private constructors. They are usually used only to avoid instantiation of utility classes, so they aren't covered by definition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1443252&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-08-10 14:20:05
|
Feature Requests item #1688923, was opened at 2007-03-26 23:29 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1688923&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: Next Release (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Puneet Sabharwal (puneetsabharwal) Assigned to: Nobody/Anonymous (nobody) Summary: XSLT for the cobertura XML report generated Initial Comment: It would be helpful if cobertura ships an XSLT along with the list of downloaded files. I have been using cobertura for quit some time for my project and its integrated with CruiseControl. The xslt i created (never wrote an xsl before!), has been integrated with CC. So when the results are published (via email from CC), we get a great looking summary from cobertura along with rest of the details that CC publishes. This summary is the same what the frames_summary.html shows. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-08-10 07:20 Message: Logged In: NO Maybe you could share your xsl file with the rest of us. I'm also looking for a xslt for the xml results of cobertura. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1688923&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-07-10 17:30:25
|
Feature Requests item #1751368, was opened at 2007-07-10 12:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1751368&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: aalmiray (aalmiray) Assigned to: Nobody/Anonymous (nobody) Summary: Support Groovy source code Initial Comment: Add support for Groovy source code lookup when creating the report. Some pointers can be found at http://www.ibm.com/developerworks/forums/dw_thread.jsp?forum=812&message=13802236&thread=112285&cat=10 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1751368&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-06-06 10:02:12
|
Feature Requests item #1510562, was opened at 2006-06-22 12:52 Message generated for change (Comment added) made by hugopalma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1510562&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Include an overall coverage summary in the HTML report Initial Comment: Include an overall coverage summary on the "All packages" page of the HTML report. See Clover for an example. ---------------------------------------------------------------------- Comment By: Hugo Palma (hugopalma) Date: 2007-06-06 11:02 Message: Logged In: YES user_id=758295 Originator: NO +1 on this one. I find it very important to have the overall coverage statistics in the start page of the report. I like to to check the overall health of the project every day, and the overall coverage statistics is a very important metric. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1510562&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-05-29 07:02:37
|
Feature Requests item #1727274, was opened at 2007-05-29 03:00 Message generated for change (Settings changed) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1727274&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Mark Doliner (thekingant) Assigned to: Nobody/Anonymous (nobody) Summary: Testing cobertura-featurerequest mailing list Initial Comment: test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1727274&group_id=130558 |
|
From: SourceForge.net <no...@so...> - 2007-05-29 07:00:32
|
Feature Requests item #1727274, was opened at 2007-05-29 03:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1727274&group_id=130558 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Doliner (thekingant) Assigned to: Nobody/Anonymous (nobody) Summary: Testing cobertura-featurerequest mailing list Initial Comment: test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=720018&aid=1727274&group_id=130558 |
