[
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.
