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