You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Timo Rantalaiho (JIRA)" <ji...@apache.org> on 2008/04/22 06:23:21 UTC
[jira] Created: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
------------------------------------------------------------------------------------------------
Key: BUILDR-62
URL: https://issues.apache.org/jira/browse/BUILDR-62
Project: Buildr
Issue Type: Bug
Components: Test frameworks
Affects Versions: 1.3
Reporter: Timo Rantalaiho
If I understand correctly, in test_frameworks.rb
http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
JUnit tests are collected by taking
1) everything that extends JUnit 3 TestCase
2) every class that is annotated with JUnit 4 @Test
3) every method that is annotated with JUnit 4 @Test
2) is clearly wrong, as @Test only applies to methods, not classes
http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (BUILDR-62) JUnit test filtering
should allow custom filtering, and not test JUnit @Test annotation on class
Posted by "Pekka Enberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591218#action_12591218 ]
penberg edited comment on BUILDR-62 at 4/21/08 11:31 PM:
--------------------------------------------------------------
One of the biggest strengths of JDave is the fact that it doesn't _need_ any special tools support so I consider dropping this from Buildr 1.3 a serious regression. Especially considering how Buildr doesn't support JDave "natively" I strongly encourage you to merge this patch (or some other version of the patch) as a stop-gap measure so that existing users can upgrade to 1.3.
Furthermore, keep in mind that @RunWith _is not_ specific to JDave at all so you're potentially breaking other working setups as well here.
was (Author: penberg):
One of the biggest strengths of JDave is the fact that it doesn't _need_ any special tools support so I consider dropping this from Buildr 1.3 a serious regression. Especially considering how Buildr doesn't support JDave "natively" I strongly encourage you to merge this patch (or some other version of the patch) as a stop-gap measure so that existing users can upgrade to 1.3.
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Pekka Enberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591218#action_12591218 ]
Pekka Enberg commented on BUILDR-62:
------------------------------------
One of the biggest strengths of JDave is the fact that it doesn't _need_ any special tools support so I consider dropping this from Buildr 1.3 a serious regression. Especially considering how Buildr doesn't support JDave "natively" I strongly encourage you to merge this patch (or some other version of the patch) as a stop-gap measure so that existing users can upgrade to 1.3.
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Pekka Enberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591231#action_12591231 ]
Pekka Enberg commented on BUILDR-62:
------------------------------------
Okay, as long as we can include/exclude specific suites annotated with @RunWith, existing JDave and JUnit4 will work just fine. Thanks.
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591215#action_12591215 ]
Assaf Arkin commented on BUILDR-62:
-----------------------------------
Right. #2 should be RunWith, not Test.
Running JDave with the JUnit framework will not be supported in 1.3 or future versions. Rather, we added more abstraction and convenience methods to support easily adding new test frameworks, so JDave should have its own test framework. Since it's BDD, it might be easier to start with TestFramework::JavaBDD (buildr/java/bdd_frameworks.rb).
It's still possible to select a subset of the available test cases using include/exclude, and these are applied uniformly across all test frameworks.:
1. The test framework identifies all the tests is can run and provides their name
2. The include/exclude patterns are applied to select the tests that will actually execute
3. Integration tests are selected separately from unit tests (integration and test tasks, respectively)
4. The resulting list is then passed back to the test framework for execution
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591232#action_12591232 ]
Assaf Arkin commented on BUILDR-62:
-----------------------------------
I just committed this fix to SVN and also verified that the following will work:
1. JUnit will pick any class that has one or more @Test annotated method in it.
2. JUnit will also pick any class that has @RunWith annotation on it, or extends TestCase (for JUnit 3.x support).
3. When using test.include('foo') only the name 'foo' is passed to JUnit for execution, provided that 'foo' is either #1 or #2.
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Timo Rantalaiho (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591193#action_12591193 ]
Timo Rantalaiho commented on BUILDR-62:
---------------------------------------
By testing @RunWith instead of @Test on class level, JDave integration becomes possible, but this does not yet solve the whole problem (that of custom suites).
----------- clip ---------------------------------------------------------------------------------------------------
Index: lib/buildr/java/test_frameworks.rb
===================================================================
--- lib/buildr/java/test_frameworks.rb (revision 649351)
+++ lib/buildr/java/test_frameworks.rb (working copy)
@@ -179,7 +179,7 @@
def tests(dependencies) #:nodoc:
filter_classes(dependencies,
:interfaces => %w{junit.framework.TestCase},
- :class_annotations => %w{org.junit.Test},
+ :class_annotations => %w{org.junit.runner.RunWith},
:method_annotations => %w{org.junit.Test})
end
----------- /clip ---------------------------------------------------------------------------------------------------
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (BUILDR-62) JUnit test filtering should allow custom
filtering, and not test JUnit @Test annotation on class
Posted by "Timo Rantalaiho (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timo Rantalaiho closed BUILDR-62.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.3
Thanks Assaf, with @RunWith + include / exclude things seem to work!
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
> Fix For: 1.3
>
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Pekka Enberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591222#action_12591222 ]
Pekka Enberg commented on BUILDR-62:
------------------------------------
And btw, how do you plan to handle JUnit 4 suites that also use the @RunWith mechanism? You need to be able to include/exclude suites from the Buildr build all the same. So as long as you support JUnit4 properly, there's no reason why JDave wouldn't work.
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BUILDR-62) JUnit test filtering should allow
custom filtering, and not test JUnit @Test annotation on class
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591229#action_12591229 ]
Assaf Arkin commented on BUILDR-62:
-----------------------------------
What Buildr 1.3 doesn't support is allowing you to use the JUnit test framework to run tests that are not identifiable by either JUnit 3 extension or JUnit 4 annotation. That has caused problems in the past, and we fixed that for 1.3.
The class annotation being @Test instead of @RunWith is a bug that's getting fixed right now (silly editing error). I'm adding a test case to make sure it will remain @RunWith moving forward.
> JUnit test filtering should allow custom filtering, and not test JUnit @Test annotation on class
> ------------------------------------------------------------------------------------------------
>
> Key: BUILDR-62
> URL: https://issues.apache.org/jira/browse/BUILDR-62
> Project: Buildr
> Issue Type: Bug
> Components: Test frameworks
> Affects Versions: 1.3
> Reporter: Timo Rantalaiho
>
> If I understand correctly, in test_frameworks.rb
> http://svn.apache.org/repos/asf/incubator/buildr/trunk/lib/buildr/java/test_frameworks.rb
> JUnit tests are collected by taking
> 1) everything that extends JUnit 3 TestCase
> 2) every class that is annotated with JUnit 4 @Test
> 3) every method that is annotated with JUnit 4 @Test
> 2) is clearly wrong, as @Test only applies to methods, not classes
> http://junit.sourceforge.net/javadoc_40/org/junit/Test.html
> Also, I found no way to run JDave ( http://www.jdave.org/ ) specs or a custom suite with the current 1.3 trunk (22 April 2008). In 1.2, this is very easy with Buildr::Java::JUnit::JUNIT_TESTS_PATTERN filtering by test / spec class names.
> Some kind of an abstraction for filtering the relevant test or spec classes is important not only for custom test framework integration, but for custom suites in big projects. Running a lot of tests is typically faster in a suite, and when you have different sets of tests (unit, integration, acceptance, black-box against a deployed application, ...) you typically want to specify which set to run. For example, the continuous integration server might only run tests against the deployed application a couple of times a day, but unit tests all the time for fast feedback. Different grouping methods of test frameworks are framework specific, and rather than making Buildr support framework specific ways, it could operate on an extra abstraction level.
> Filtering by class name has worked well elsewhere (ant, maven, buildr 1.2), so it would be excellent if it would be included in 1.3 as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.