You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ken Arnold (JIRA)" <ji...@codehaus.org> on 2006/06/05 15:38:43 UTC
[jira] Created: (SUREFIRE-44) Inner class inclusion too powerful
Inner class inclusion too powerful
----------------------------------
Key: SUREFIRE-44
URL: http://jira.codehaus.org/browse/SUREFIRE-44
Project: surefire
Type: Bug
Versions: 2.0
Reporter: Ken Arnold
When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
It is not name based -- it assumes that all inner classes of an included class are test cases.
It does not work on nested classes (non-static classes)
See the test case and stack trace below.
I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
I have been puzzling myself over errors like the following:
java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
RUN ABORTED
java.lang.NoSuchMethodException
Test code:
public class TestAThing {
public class Foo { }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=all ]
Brett Porter updated SUREFIRE-44:
---------------------------------
Fix Version/s: 2.1
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: surefire
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Ken Arnold
> Fix For: 2.1
>
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Ken Arnold (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=comments#action_66613 ]
Ken Arnold commented on SUREFIRE-44:
------------------------------------
I thought I had a workaround -- make classes static, etc. But I don't. Because of things like this:
public interface MockExpressionMatcher {
MockExpressionMatcher MATCH_ALL = new MockExpressionMatcher() {
public boolean matches(String sql) {
return true;
}
};
boolean matches(String sql);
}
When I use it in code, the anonymous object for MATCH_ALL is created in that class. Or at least it seems so. Consider:
private MockDBConnection setupTestDB() {
MockDBConnection c = new MockDBConnection();
c.addResultSetFactory(MockExpressionMatcher.MATCH_ALL,
new MockUpdateFactory());
return c;
}
I then get the following problem when running tests:
java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.TestComputeQuery$1.<init>()
This is true -- a javap of this anonymous class shows no constructor at all:
class com.hyphenhealth.edc.drq.editchecks.queries.TestComputeQuery$1 extends java.lang.Object{
}
I cannot control this compiler behavior. This is how it handles static final constructed objects (in interfaces anyway). I cannot make this class non-static because this is not my file. (I probably could make a nested static class for each such field if I controlled the file).
If there is a language for exclusion of nested classes I cannot find it in the documentation. So I'm out of workarounds for now.
(This is partly a consequence of naming java files instead of classes for inclusion/exclusion. If classes were named I could exclude **/*\$* (all nested classes). But nested classes have no separate file to include/exclude. I will file a separate feature request for that.)
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: surefire
> Type: Bug
> Versions: 2.0
> Reporter: Ken Arnold
>
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Dan Fabulich (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Fabulich closed SUREFIRE-44.
--------------------------------
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.4)
Can't reproduce; integration checked in revision 597570
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 2.0 (2.2 plugin)
> Reporter: Ken Arnold
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Ken Arnold (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=comments#action_82842 ]
Ken Arnold commented on SUREFIRE-44:
------------------------------------
No, I meant that I was using 1.5.3 when I had the problem, and that I hadn't tried it at 2.0. Sorry for the unclarity.
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: surefire
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Ken Arnold
> Fix For: 2.1
>
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated SUREFIRE-44:
---------------------------------
Fix Version/s: (was: 2.3)
2.4
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 2.0 (2.2 plugin)
> Reporter: Ken Arnold
> Fix For: 2.4
>
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Ken Arnold (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=comments#action_66951 ]
Ken Arnold commented on SUREFIRE-44:
------------------------------------
My mistake, this is not a 2.0 issue (that was a typo). It's a 1.5.3 issue.
I am going to have to add no-arg constructors to all nested classes right now. This is just wrong.
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: surefire
> Type: Bug
> Versions: 2.0
> Reporter: Ken Arnold
>
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-44) Inner class inclusion too powerful
Posted by "Carlos Sanchez (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=comments#action_82637 ]
Carlos Sanchez commented on SUREFIRE-44:
----------------------------------------
do you mean you are having this issue in 1.5.3 and it's already fixed in 2.0 ?
> Inner class inclusion too powerful
> ----------------------------------
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: surefire
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Ken Arnold
> Fix For: 2.1
>
>
> When inner classes were included, it was done in a way that was too powerful. I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for other reasons (simple mock objects, for example). Inner classes do not have no-arg constructors, and so including them includes classes that pretty much by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else, nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of top-level classes is much more selective. I would prefer if the default inclusion of nested classes followed the same default naming pattern. But at the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException: com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.<init>()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at org.apache.maven.surefire.battery.JUnitBattery.<init>(JUnitBattery.java:81)
> at org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira