On Feb 25, 2008, at 7:50 PM, Tal Rotbart wrote:
I don't think Ant complains with Junit4 tests. At least it doesn't for
me (I've manually removed that filter for my build, and it never
complained with Buildr 1.2.x). Maybe only if you have no @Test
annotated methods in the class you are trying to run.
TestCase is deprecated if I'm not mistaken, so we can't rely on that,
instead I can write a filter that will check if there's at least one
@Test annotated method in the class, but that might slow down the
build.
I added a check for the org.junit.Test annotation, can you try it out?
Assaf
Cheers,
Tal
On Tue, Feb 26, 2008 at 2:45 PM, Assaf Arkin <[EMAIL PROTECTED]>
wrote:
On Feb 25, 2008, at 7:19 PM, Tal Rotbart wrote:
Alright, did that the candidates seem alright. It is the output of
the
JUnitTestFilter that is empty.
From the filter's java code it seems to assume that the test would
be
an instance of junit.framework.TestCase, which AFAIK isn't the case
with Junit4 (See
http://junit.sourceforge.net/doc/cookbook/cookbook.htm), and isn't
the
case with my test classes.
Did I miss some setting in the buildfile that wasn't required before
1.3?
1.2 would decide what a good candidate is based on the class name,
looking for Test* or *Test. That wasn't the most loved feature, it's
a good convention but if you have a class that's not a test case with
a matching name, Ant complains.
So 1.3 is trying to figure out which classes are test cases, before
handing those off to Ant. I'm not sure how we could do annotations,
but that's one possibility. Worse case, we can always revert back.
Assaf
Cheers,
Tal
On Tue, Feb 26, 2008 at 12:13 PM, Assaf Arkin <[EMAIL PROTECTED]>
wrote:
On Feb 25, 2008, at 2:56 PM, Tal Rotbart wrote:
task.tests reports an empty array ("[]").
I verified that the compile task compiled test classes to the <sub
project>/target/test/classes/<package hierarchy>/ folder. Note
that
the same buildfile works perfectly with buildr 1.2.x on another
machien running Ubuntu.
The sub-project's define:
define "data" do
compile.with COMMONS_LANG, project("model"), XSTREAM
test.compile.with TEST_DEPENDENCIES, project("test-common")
test.with TEST_DEPENDENCIES, project("model"), project("test-
common")
test.enhance do |task|
p "Available tests: "
p task.tests
end
package(:jar)
end
Any more hints on where to look for the source of the issue?
The test cases are filtered in lib/java/test_frameworks.rb, line
126.
This method basically runs through all the classes appearing in
target/
test/classes and filters the one it thinks are valid test cases.
Maybe a few puts statement there to see why it's not picking on
your
test cases.
Assaf
Cheers,
Tal
On Tue, Feb 26, 2008 at 9:42 AM, Assaf Arkin <[EMAIL PROTECTED]>
wrote:
On Feb 25, 2008, at 2:35 PM, Tal Rotbart wrote:
I do not see the difference between jruby /usr/bin/buildr and
jruby -s
buildr. They both run the exact same script, and with both
commands
buildr trunk pretend to perform the tests but do not actually do
them.
They will both run the same script. I'm not seeing any problem
running tests in trunk, tested against JUnit.
Try to find out what tests are being picked up:
test.enhance do |task|
p "Available tests: "
p task.tests
end
Assaf
Any clue would be greatly appreciated,
Cheers,
Tal
On Tue, Feb 26, 2008 at 3:49 AM, Victor Hugo Borja <[EMAIL PROTECTED]
wrote:
Tal,
On Sun, Feb 24, 2008 at 9:29 PM, Tal Rotbart <[EMAIL PROTECTED]
>
wrote:
Weird. I just noticed Buildr pretends to run my tests but
doesn't,this is
under jruby.
Steps I took:
1. Downloaded jruby
2. Added it to my PATH
3. Verified 'which rake', 'which gem' point to the jruby.
4. Installed buildr into jruby gems from trunk by using 'rake
install'.
5. Running buildr using 'jruby /usr/bin/buildr clean
package' (My
/usr/bin/buildr's content is listed below.)
In step 5, you should be able to run buildr with 'jruby -S
buildr'
or simply
with 'builldr' if the JRuby version is first on your path.
I guess /usr/bin/buildr is your script for MRI and would not
work
with JRuby
as it requires rjb.
Cheers,
--
vic
Quaerendo invenietis.
