Mailing-List: contact buildr-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: buildr-dev@incubator.apache.org
Message-ID: <230937724.1208845522331.JavaMail.jira@brutus>
Date: Mon, 21 Apr 2008 23:25:22 -0700 (PDT)
From: "Assaf Arkin (JIRA)" <jira@apache.org>
To: buildr-commits@incubator.apache.org
Subject: [jira] Commented: (BUILDR-62) JUnit test filtering should allow
 custom filtering, and not test JUnit @Test annotation on class
In-Reply-To: <519976049.1208838201649.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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