I think this happens if you have two versions of Ant on the classpath.

Marián


dave.alvarado@... wrote:
> Hi,
>
> I'm using Eclipse 3.4 (WinXP) with Ant 1.7.  I'm trying to run a JUnit test
and get the error below
>
> Buildfile: C:\Temp\CedarPoint_Service\build-junit-test.xml
> check-junit:
> build-tests:
>     [javac] Compiling 9 source files to C:\Temp\CedarPoint_Service\classes
>      [copy] Copying 2 files to C:\Temp\CedarPoint_Service\classes
> run-query-test:
>     [junit] java.io.FileNotFoundException:
C:\Temp\CedarPoint_Service\junitvmwatcher1903248725.properties (The system
cannot find the file specified)
>     [junit]  at java.io.FileInputStream.open(Native Method)
>     [junit]  at java.io.FileInputStream.<init>(FileInputStream.java:106)
>     [junit]  at java.io.FileReader.<init>(FileReader.java:55)
>     [junit]  at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask\
.java:1028)
>     [junit]  at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:81\
7)
>     [junit]  at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.\
java:1657)
>     [junit]  at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:76\
4)
>     [junit]  at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
>     [junit]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     [junit]  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [junit]  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav\
a:25)
>     [junit]  at java.lang.reflect.Method.invoke(Method.java:585)
>     [junit]  at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
>     [junit]  at org.apache.tools.ant.Task.perform(Task.java:348)
>     [junit]  at org.apache.tools.ant.Target.execute(Target.java:357)
>     [junit]  at org.apache.tools.ant.Target.performTasks(Target.java:385)
>     [junit]  at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
>     [junit]  at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
>     [junit]  at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:\
41)
>     [junit]  at
org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(Ecl\
ipseDefaultExecutor.java:32)
>     [junit]  at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
>     [junit]  at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.j\
ava:423)
>     [junit]  at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.\
java:137)
>
> BUILD FAILED
> C:\Temp\CedarPoint_Service\build-junit-test.xml:118: Test QuerySubscriberTest
failed (crashed)
>
> Total time: 12 seconds
>
>
> I have no idea what this means or know how to begin to troubleshoot.  Please
help.  The ant task in question is also listed below ...
>
>   <target name="run-query-test" depends="build-tests">
>    <junit dir="${build}" fork="true" haltonfailure="true">
>   	  <classpath>
>     	  <path refid="project.class.path"/>
>         <pathelement path="${java.class.path}"/>
>         <pathelement path="${dist}/cedarpointpooledclient.jar"/>
>         <pathelement path="${build}"/>
>   	  </classpath>
>   	  <test name="QuerySubscriberTest" todir="${docs}"
outfile="junit.query.result">
>   		  <formatter type="xml"/>
>   	  </test>
>    </junit>
>   </target>

All,

We are considering moving to Google Code (and thus Subversion) for its
superior code review features. However, before doing so we'd like to know
who else would be affected by such a change. If a project you run would be
affected, please let us know.

Regards,

Kent and David

On Tue, Dec 9, 2008 at 8:43 AM, kentb <kentb@...> wrote:
> All,
>
> We are considering moving to Google Code (and thus Subversion) for its
> superior code review features. However, before doing so we'd like to know
> who else would be affected by such a change. If a project you run would be
> affected, please let us know.
>
> Regards,
>
> Kent and David
>

Have you considered git and github ... just as a thought?

http://github.com/

Not sure how that fits in the Java space or not.

Regards
Shane

2008/12/8 Shane Mingins <shane.mingins@...>:
> Have you considered git and github ... just as a thought?
>
> http://github.com/
>
> Not sure how that fits in the Java space or not.

It's more of a problem for people working on Windows.  As far as I
know, the only DVCS that works well on Windows is Bazaar.

--Nat

kentb schrieb:

> We are considering moving to Google Code (and thus Subversion) for its
> superior code review features. However, before doing so we'd like to know
> who else would be affected by such a change. If a project you run would be
> affected, please let us know.

Google Code denies access from restricted countries. I found that out
when I was doing vacation in Cuba and tried to download the current
version of GWT.


Regards, Lothar

Very interesting. That doesn't align with my values. Still, David and I
would like a less-synchronous-but-still-connected style of development. For
that we need good code review tools. Google Code provides those in spades.
Is there something equivalent for Git?

Cheers,

Kent Beck
Three Rivers Institute

   _____

From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
Lothar Kimmeringer
Sent: Tuesday, December 09, 2008 1:48 AM
To: junit@yahoogroups.com
Subject: Re: [junit] Would JUnit moving to Subversion and/or Google Code
have consequences for you?



kentb schrieb:

> We are considering moving to Google Code (and thus Subversion) for its
> superior code review features. However, before doing so we'd like to know
> who else would be affected by such a change. If a project you run would be
> affected, please let us know.

Google Code denies access from restricted countries. I found that out
when I was doing vacation in Cuba and tried to download the current
version of GWT.

Regards, Lothar





[Non-text portions of this message have been removed]

Actually, it appears that JUnit has already been somewhat blocked from Cuba:

http://en.wikipedia.org/wiki/SourceForge#Banned_countries

So now we have three variables to control:

1) Code review ease
2) Source control ease
3) Worldwide access

Does anyone know for sure if there's a hosting solution that scores 100% on
Worldwide Access?  Does anyone know what the restrictions involve?  (I
wonder if it's something to do with SSL connections from countries to which,
theoretically, you can't export SSL-enabling technology, or couldn't at one
point--I'm very rusty on this).

It appears that if we allow browsing the documentation and downloading
through junit.org, and other services through Google Code, we'd be offering
the same level of worldwide access we are now.  Is that true?

    David Saff

On Tue, Dec 9, 2008 at 12:45 PM, kentb <kentb@...> wrote:

>   Very interesting. That doesn't align with my values. Still, David and I
> would like a less-synchronous-but-still-connected style of development. For
> that we need good code review tools. Google Code provides those in spades.
> Is there something equivalent for Git?
>
> Cheers,
>
> Kent Beck
> Three Rivers Institute
>
> _____
>
> From: junit@yahoogroups.com <junit%40yahoogroups.com> [mailto:
> junit@yahoogroups.com <junit%40yahoogroups.com>] On Behalf Of
> Lothar Kimmeringer
> Sent: Tuesday, December 09, 2008 1:48 AM
> To: junit@yahoogroups.com <junit%40yahoogroups.com>
> Subject: Re: [junit] Would JUnit moving to Subversion and/or Google Code
> have consequences for you?
>
>
> kentb schrieb:
>
> > We are considering moving to Google Code (and thus Subversion) for its
> > superior code review features. However, before doing so we'd like to know
> > who else would be affected by such a change. If a project you run would
> be
> > affected, please let us know.
>
> Google Code denies access from restricted countries. I found that out
> when I was doing vacation in Cuba and tried to download the current
> version of GWT.
>
> Regards, Lothar
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

One service that I'm quite interested in is Launchpad. I mirror
NUnit 2.5 there and have several related projects hosted. NUnit
  3.0 will be moving there. The VCS on Launchpad is bazaar.

The main attraction of Launchpad to me was their stated
goal of making it very easy for people to contribute to
projects. Anyone who wants to create a branch of a project
in their private space on launchpad can do so and then
propose the change for merging into the trunk. Of course,C
the project team has control over what they accept.

While working on such a branch, the potential contributor
has all the services of a source code management system
available to them on their own machine and can push
updates to a published branch on Launchpad. Regular
contributors or team members can do the same thing and
you can use your main branch (trunk) like a centralized
repository if you prefer, while still having the benefits
of a distributed system where you need it. Code review
is integrated in the process.

I'm still in the stage of learning to use LP and bzr,
and there could still be glitches, but both are under
active development and the underlying philosophy matches
what I'd like to do. I suspect it's a philosophical match
you as well. I spent some time searching and couldn't
find anything about banning any countries there.

Launchpad, btw, is sponsored by Canonical, and it's
where Ubuntu is developed, so it focuses on an international
audience and has a platform for localization as well.

I suggest taking the tour at http://launchpad.net/+tour/index
if this sounds at all interesting.

Charlie

> -----Original Message-----
> From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On
> Behalf Of David Saff
> Sent: Tuesday, December 09, 2008 11:07 AM
> To: junit@yahoogroups.com
> Subject: Re: [junit] Would JUnit moving to Subversion and/or
> Google Code have consequences for you?
>
> Actually, it appears that JUnit has already been somewhat
> blocked from Cuba:
>
> http://en.wikipedia.org/wiki/SourceForge#Banned_countries
>
> So now we have three variables to control:
>
> 1) Code review ease
> 2) Source control ease
> 3) Worldwide access
>
> Does anyone know for sure if there's a hosting solution that
> scores 100% on Worldwide Access?  Does anyone know what the
> restrictions involve?  (I wonder if it's something to do with
> SSL connections from countries to which, theoretically, you
> can't export SSL-enabling technology, or couldn't at one
> point--I'm very rusty on this).
>
> It appears that if we allow browsing the documentation and
> downloading through junit.org, and other services through
> Google Code, we'd be offering the same level of worldwide
> access we are now.  Is that true?
>
>    David Saff
>
> On Tue, Dec 9, 2008 at 12:45 PM, kentb <kentb@...> wrote:
>
> >   Very interesting. That doesn't align with my values. Still, David
> > and I would like a less-synchronous-but-still-connected style of
> > development. For that we need good code review tools.
> Google Code provides those in spades.
> > Is there something equivalent for Git?
> >
> > Cheers,
> >
> > Kent Beck
> > Three Rivers Institute
> >
> > _____
> >
> > From: junit@yahoogroups.com <junit%40yahoogroups.com> [mailto:
> > junit@yahoogroups.com <junit%40yahoogroups.com>] On Behalf
> Of Lothar
> > Kimmeringer
> > Sent: Tuesday, December 09, 2008 1:48 AM
> > To: junit@yahoogroups.com <junit%40yahoogroups.com>
> > Subject: Re: [junit] Would JUnit moving to Subversion and/or Google
> > Code have consequences for you?
> >
> >
> > kentb schrieb:
> >
> > > We are considering moving to Google Code (and thus
> Subversion) for
> > > its superior code review features. However, before doing so we'd
> > > like to know who else would be affected by such a change. If a
> > > project you run would
> > be
> > > affected, please let us know.
> >
> > Google Code denies access from restricted countries. I
> found that out
> > when I was doing vacation in Cuba and tried to download the current
> > version of GWT.
> >
> > Regards, Lothar
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I forgot to mention... you would still need to host your
website and wiki somewhere else - LP doesn't provide them.
I felt that was a minor issue for me.

Charlie

> -----Original Message-----
> From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On
> Behalf Of Charlie Poole
> Sent: Tuesday, December 09, 2008 12:10 PM
> To: junit@yahoogroups.com
> Subject: RE: [junit] Would JUnit moving to Subversion and/or
> Google Code have consequences for you?
>
> One service that I'm quite interested in is Launchpad. I
> mirror NUnit 2.5 there and have several related projects
> hosted. NUnit  3.0 will be moving there. The VCS on Launchpad
> is bazaar.
>
> The main attraction of Launchpad to me was their stated goal
> of making it very easy for people to contribute to projects.
> Anyone who wants to create a branch of a project in their
> private space on launchpad can do so and then propose the
> change for merging into the trunk. Of course,C the project
> team has control over what they accept.
>
> While working on such a branch, the potential contributor has
> all the services of a source code management system available
> to them on their own machine and can push updates to a
> published branch on Launchpad. Regular contributors or team
> members can do the same thing and you can use your main
> branch (trunk) like a centralized repository if you prefer,
> while still having the benefits of a distributed system where
> you need it. Code review is integrated in the process.
>
> I'm still in the stage of learning to use LP and bzr, and
> there could still be glitches, but both are under active
> development and the underlying philosophy matches what I'd
> like to do. I suspect it's a philosophical match you as well.
> I spent some time searching and couldn't find anything about
> banning any countries there.
>
> Launchpad, btw, is sponsored by Canonical, and it's where
> Ubuntu is developed, so it focuses on an international
> audience and has a platform for localization as well.
>
> I suggest taking the tour at http://launchpad.net/+tour/index
> if this sounds at all interesting.
>
> Charlie
>
> > -----Original Message-----
> > From: junit@yahoogroups.com [mailto:junit@yahoogroups.com]
> On Behalf
> > Of David Saff
> > Sent: Tuesday, December 09, 2008 11:07 AM
> > To: junit@yahoogroups.com
> > Subject: Re: [junit] Would JUnit moving to Subversion and/or Google
> > Code have consequences for you?
> >
> > Actually, it appears that JUnit has already been somewhat
> blocked from
> > Cuba:
> >
> > http://en.wikipedia.org/wiki/SourceForge#Banned_countries
> >
> > So now we have three variables to control:
> >
> > 1) Code review ease
> > 2) Source control ease
> > 3) Worldwide access
> >
> > Does anyone know for sure if there's a hosting solution that scores
> > 100% on Worldwide Access?  Does anyone know what the restrictions
> > involve?  (I wonder if it's something to do with SSL
> connections from
> > countries to which, theoretically, you can't export SSL-enabling
> > technology, or couldn't at one point--I'm very rusty on this).
> >
> > It appears that if we allow browsing the documentation and
> downloading
> > through junit.org, and other services through Google Code, we'd be
> > offering the same level of worldwide access we are now.  Is
> that true?
> >
> >    David Saff
> >
> > On Tue, Dec 9, 2008 at 12:45 PM, kentb <kentb@...> wrote:
> >
> > >   Very interesting. That doesn't align with my values.
> Still, David
> > > and I would like a less-synchronous-but-still-connected style of
> > > development. For that we need good code review tools.
> > Google Code provides those in spades.
> > > Is there something equivalent for Git?
> > >
> > > Cheers,
> > >
> > > Kent Beck
> > > Three Rivers Institute
> > >
> > > _____
> > >
> > > From: junit@yahoogroups.com <junit%40yahoogroups.com> [mailto:
> > > junit@yahoogroups.com <junit%40yahoogroups.com>] On Behalf
> > Of Lothar
> > > Kimmeringer
> > > Sent: Tuesday, December 09, 2008 1:48 AM
> > > To: junit@yahoogroups.com <junit%40yahoogroups.com>
> > > Subject: Re: [junit] Would JUnit moving to Subversion
> and/or Google
> > > Code have consequences for you?
> > >
> > >
> > > kentb schrieb:
> > >
> > > > We are considering moving to Google Code (and thus
> > Subversion) for
> > > > its superior code review features. However, before
> doing so we'd
> > > > like to know who else would be affected by such a change. If a
> > > > project you run would
> > > be
> > > > affected, please let us know.
> > >
> > > Google Code denies access from restricted countries. I
> > found that out
> > > when I was doing vacation in Cuba and tried to download
> the current
> > > version of GWT.
> > >
> > > Regards, Lothar
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--- In junit@yahoogroups.com, "Nat Pryce" <nat.pryce@...> wrote:
>
> 2008/12/8 Shane Mingins <shane.mingins@...>:
> > Have you considered git and github ... just as a thought?
> >
> > http://github.com/
> >
> > Not sure how that fits in the Java space or not.
>
> It's more of a problem for people working on Windows.  As far as I
> know, the only DVCS that works well on Windows is Bazaar.
>

Mercurial also works well on Windows --- one of the reasons why it is
now used by Sun for the OpenJDK.

I know sharesource http://www.sharesource.org hosts both mercurial and
SVN, I'm not sure whether the same source can be accessed in both ways
or not. We are using mercurial at my company and it works well on both
windox, linux and mac. What is mainly lacking is good ide support but
I say that netbeans support mercurial natively now so maybe that is
worth a try.

Sharesource does not seem to have any export restrictions but is
lacking review features as far as I know. But it has this certain warm
fuzzy family "niceness" to it and does not feel as big and bulky as
sourceforge does. I felt had to mention sharesource because I like it,
I also think that whatever is lacking in features would be looked into
in order to accomodate such a well known project such as JUnit, but
thats just how I reasoning if I was running sharesource :)

In my book a distributed vcs such as Git, mercurial or bazaar would be
a big plus.
/J

On Tue, Dec 9, 2008 at 8:24 PM, mark_p_thornton
<mark.p.thornton@...> wrote:
> --- In junit@yahoogroups.com, "Nat Pryce" <nat.pryce@...> wrote:
>>
>> 2008/12/8 Shane Mingins <shane.mingins@...>:
>
>> > Have you considered git and github ... just as a thought?
>> >
>> > http://github.com/
>> >
>> > Not sure how that fits in the Java space or not.
>>
>> It's more of a problem for people working on Windows. As far as I
>> know, the only DVCS that works well on Windows is Bazaar.
>>
>
> Mercurial also works well on Windows --- one of the reasons why it is
> now used by Sun for the OpenJDK.
>
>



--
-----------------------------------------------------
Joakim Ohlrogge
Agical AB
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN

Mobile: +46-708-754004
Blog: johlrogge.wordpress.com
E-mail: joakim.ohlrogge@...

I think we'd be hard-pressed to find another hosting solution that feels as
bulky as SourceForge.  I also think it's easy to over-state JUnit's
importance to a hosting provider: as far as I know, we've never cracked the
top 50 projects at SourceForge--we release rather infrequently, and many,
many people get JUnit for free with Eclipse, maven, etc.

    David Saff

On Wed, Dec 10, 2008 at 12:59 PM, Joakim Ohlrogge <joakim.ohlrogge@...
> wrote:

>   I know sharesource http://www.sharesource.org hosts both mercurial and
> SVN, I'm not sure whether the same source can be accessed in both ways
> or not. We are using mercurial at my company and it works well on both
> windox, linux and mac. What is mainly lacking is good ide support but
> I say that netbeans support mercurial natively now so maybe that is
> worth a try.
>
> Sharesource does not seem to have any export restrictions but is
> lacking review features as far as I know. But it has this certain warm
> fuzzy family "niceness" to it and does not feel as big and bulky as
> sourceforge does. I felt had to mention sharesource because I like it,
> I also think that whatever is lacking in features would be looked into
> in order to accomodate such a well known project such as JUnit, but
> thats just how I reasoning if I was running sharesource :)
>






>
>
> In my book a distributed vcs such as Git, mercurial or bazaar would be
> a big plus.
> /J
>
>
> On Tue, Dec 9, 2008 at 8:24 PM, mark_p_thornton
> <mark.p.thornton@... <mark.p.thornton%40ntlworld.com>> wrote:
> > --- In junit@yahoogroups.com <junit%40yahoogroups.com>, "Nat Pryce"
> <nat.pryce@...> wrote:
> >>
> >> 2008/12/8 Shane Mingins <shane.mingins@...>:
> >
> >> > Have you considered git and github ... just as a thought?
> >> >
> >> > http://github.com/
> >> >
> >> > Not sure how that fits in the Java space or not.
> >>
> >> It's more of a problem for people working on Windows. As far as I
> >> know, the only DVCS that works well on Windows is Bazaar.
> >>
> >
> > Mercurial also works well on Windows --- one of the reasons why it is
> > now used by Sun for the OpenJDK.
> >
> >
>
> --
> -----------------------------------------------------
> Joakim Ohlrogge
> Agical AB
> Västerlånggatan 79, 2 tr
> 111 29 Stockholm, SWEDEN
>
> Mobile: +46-708-754004
> Blog: johlrogge.wordpress.com
> E-mail: joakim.ohlrogge@... <joakim.ohlrogge%40agical.se>
>
>


[Non-text portions of this message have been removed]

Does it make sense to write a single junit test to test all
classes that implement a common interface?
Is there a typical "design pattern" for this usage?
For example, the test below tests the size() method of
java.util.ArrayList.  But I would also like to have it test
the size() method of LinkedList without writing a duplicate
test method.
Thanks for any advice.


public class TestList extends junit.framework.TestCase
{
     java.util.List dogs;

     protected void setUp()
     {
         try
         {
           Class classname = Class.forName("java.util.ArrayList");
           dogs = (java.util.List) classname.newInstance();
         } catch (Exception e) {System.out.println("instantiation error");};

     }

     public void testSize()
     {
         dogs.add("Fido");
         assertEquals(1,dogs.size());
     }
}

--
View this message in context:
http://www.nabble.com/One-test-for-all-implementors-of-an-interface-tp20959803p2\
0959803.html
Sent from the JUnit - User mailing list archive at Nabble.com.


[Non-text portions of this message have been removed]

John,

There are several possibilities.  Can you use JUnit 4?

    David Saff

On Thu, Dec 11, 2008 at 12:06 PM, five ten <john_roshi@...> wrote:

>
> Does it make sense to write a single junit test to test all
> classes that implement a common interface?
> Is there a typical "design pattern" for this usage?
> For example, the test below tests the size() method of
> java.util.ArrayList. But I would also like to have it test
> the size() method of LinkedList without writing a duplicate
> test method.
> Thanks for any advice.
>
> public class TestList extends junit.framework.TestCase
> {
> java.util.List dogs;
>
> protected void setUp()
> {
> try
> {
> Class classname = Class.forName("java.util.ArrayList");
> dogs = (java.util.List) classname.newInstance();
> } catch (Exception e) {System.out.println("instantiation error");};
>
> }
>
> public void testSize()
> {
> dogs.add("Fido");
> assertEquals(1,dogs.size());
> }
> }
>
> --
> View this message in context:
>
http://www.nabble.com/One-test-for-all-implementors-of-an-interface-tp20959803p2\
0959803.html
> Sent from the JUnit - User mailing list archive at Nabble.com.
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

John...

You know, this is a good question, and I'd like to hear other responses, too.

For me, testing 'up-the-tree' has never seemed like the right thing to do.

That doesn't mean I don't sometimes wind up with a hierarchy of test
classes, e.g. FlintstonesTestBase ancestors FredTest and WilmaTest.
But I usually 'discover' this rather than set out to do it.

For me, the need for a sub-class is the need for differentiation.
That is, Fred and Wilma both support the Flintstones interface, but
they do it in different ways.  When I microtest, I use what we call
'gray-box' testing.  That is, the test takes advantage of, though not
necessarily declaring, the inside information that its author has
about the class being tested.  FredTest and WilmaTest *will* probably
share some code, hence FlintstonesTestBase, but they don't restrict
their view to only public api's of the Flintstones interface.

Does that make any sense at all, or should I try a change of meds?
Hill

Wanna learn TDD?  Try http://www.industrialllogic.com/elearning !





On Thu, Dec 11, 2008 at 12:06 PM, five ten <john_roshi@...> wrote:
>
> Does it make sense to write a single junit test to test all
> classes that implement a common interface?
> Is there a typical "design pattern" for this usage?
> For example, the test below tests the size() method of
> java.util.ArrayList. But I would also like to have it test
> the size() method of LinkedList without writing a duplicate
> test method.
> Thanks for any advice.
>
> public class TestList extends junit.framework.TestCase
> {
> java.util.List dogs;
>
> protected void setUp()
> {
> try
> {
> Class classname = Class.forName("java.util.ArrayList");
> dogs = (java.util.List) classname.newInstance();
> } catch (Exception e) {System.out.println("instantiation error");};
>
> }
>
> public void testSize()
> {
> dogs.add("Fido");
> assertEquals(1,dogs.size());
> }
> }
>
> --
> View this message in context:
>
http://www.nabble.com/One-test-for-all-implementors-of-an-interface-tp20959803p2\
0959803.html
> Sent from the JUnit - User mailing list archive at Nabble.com.
>
> [Non-text portions of this message have been removed]
>
>

I don't think the point of the question was to test "up the tree", but
to test the faithfulness of each implementation to the contract
expressed by the interface.

I have taken what I imagine is a naive approach to this by writing the
interface contract tests in an abstract base test case and extending
that test class for each implementation.  The tests in the base run
for all implementations, and the concrete classes add whatever other
tests they need for implementation corner cases or unrelated functions.

The crux of the problem is that the base tests need a way to
instantiate the class under test without knowing what class that is.
To do this, the base test class relied on an abstract factory method
implemented in each concrete test class according to the target
implementation.

Because we were using JUnit 3.8, We faced one other wrinkle.  We had
to avoid naming the base class like a test case or JUnit would choke
trying to instantiate and run it directly.

As I said, the technique was naive, but it basically worked, and it
got past the gatekeeper responsible for keeping our use of 3rd party
packages under control.  Since then, I have seen that GroboUtils
claims to support this, so you might want to check that out at:

http://groboutils.sourceforge.net/testing-junit/art_hierarchy.html

I'd love to hear about experience with that or other more elegant and
robust approaches.

Best,
Lance

--- In junit@yahoogroups.com, "Mike Hill" <mike@...> wrote:
>
> John...
>
> You know, this is a good question, and I'd like to hear other
responses, too.
>
> For me, testing 'up-the-tree' has never seemed like the right thing
to do.
>
> That doesn't mean I don't sometimes wind up with a hierarchy of test
> classes, e.g. FlintstonesTestBase ancestors FredTest and WilmaTest.
> But I usually 'discover' this rather than set out to do it.
>
> For me, the need for a sub-class is the need for differentiation.
> That is, Fred and Wilma both support the Flintstones interface, but
> they do it in different ways.  When I microtest, I use what we call
> 'gray-box' testing.  That is, the test takes advantage of, though not
> necessarily declaring, the inside information that its author has
> about the class being tested.  FredTest and WilmaTest *will* probably
> share some code, hence FlintstonesTestBase, but they don't restrict
> their view to only public api's of the Flintstones interface.
>
> Does that make any sense at all, or should I try a change of meds?
> Hill
>
> Wanna learn TDD?  Try http://www.industrialllogic.com/elearning !
>
>
>
>
>
> On Thu, Dec 11, 2008 at 12:06 PM, five ten <john_roshi@...> wrote:
> >
> > Does it make sense to write a single junit test to test all
> > classes that implement a common interface?
> > Is there a typical "design pattern" for this usage?
> > For example, the test below tests the size() method of
> > java.util.ArrayList. But I would also like to have it test
> > the size() method of LinkedList without writing a duplicate
> > test method.
> > Thanks for any advice.
> >
> > public class TestList extends junit.framework.TestCase
> > {
> > java.util.List dogs;
> >
> > protected void setUp()
> > {
> > try
> > {
> > Class classname = Class.forName("java.util.ArrayList");
> > dogs = (java.util.List) classname.newInstance();
> > } catch (Exception e) {System.out.println("instantiation error");};
> >
> > }
> >
> > public void testSize()
> > {
> > dogs.add("Fido");
> > assertEquals(1,dogs.size());
> > }
> > }
> >
> > --
> > View this message in context:
> >
http://www.nabble.com/One-test-for-all-implementors-of-an-interface-tp20959803p2\
0959803.html
> > Sent from the JUnit - User mailing list archive at Nabble.com.
> >
> > [Non-text portions of this message have been removed]
> >
> >
>

--- In junit@yahoogroups.com, "lancezant" <lance.zant@...> wrote:

> The crux of the problem is that the base tests need a way to
> instantiate the class under test without knowing what class that is.

That's EXACTLY where I was stuck.

> To do this, the base test class relied on an abstract factory method
> implemented in each concrete test class according to the target
> implementation.

Aha! Let me try that, thanks.

--john

On Thu, Dec 11, 2008 at 1:36 PM, lancezant <lance.zant@...> wrote:

> The crux of the problem is that the base tests need a way to
> instantiate the class under test without knowing what class that is.
> To do this, the base test class relied on an abstract factory method
> implemented in each concrete test class according to the target
> implementation.
>
A more flexible solution would be to use Guice (or any other independency
framework, but I love the elegance and cleverness of Guice).

Your test class should only ever see the interface and you should use a
@DataProvider/ParameterizedTest to inject the various implementations from
the outside.

--
***Cédric
http://testng.org
*


[Non-text portions of this message have been removed]

--- In junit@yahoogroups.com, "lancezant" <lance.zant@...> wrote:
> I have taken what I imagine is a naive approach to this by writing
the
> interface contract tests in an abstract base test case and extending
> that test class for each implementation.  The tests in the base run
> for all implementations, and the concrete classes add whatever other
> tests they need for implementation corner cases or unrelated
functions.
>

Great, I followed your suggestion and it works. This may not
be exactly what you described, but it works for me:

public abstract class BaseTest extends junit.framework.TestCase
{
     java.util.List<String> dogs;

     protected void setUp()
     {
         dogs = create();
     }

     public abstract java.util.List<String> create();

     public void testSize()
     {
         dogs.add("Fido");
         assertEquals(1,dogs.size());
     }
}


public class ArrayListTest extends BaseTest
{
     public java.util.ArrayList<String> create()
     {
         return new java.util.ArrayList<String>();
     }

}

public class LinkedListTest extends BaseTest
{
     public java.util.LinkedList<String> create()
     {
         return new java.util.LinkedList<String>();
     }

}

Thanks very much!
--john

How consolidated does your choice have to be? I guess I'm after a
better definition of the problems that you're trying to solve that
have bitten you with the existing infrastructure (other than
SourceForge availability issues in the past!).

You could just take a best-of-breed approach and pick 'n mix various
things. e.g. if you're talking about the Google Code code review
tools, I would imagine that they're similar to this:

http://codereview.appspot.com/

So far, I've found that I like JIRA the best for bug tracking. I think
you could use codehaus for that. There might be other options too.

Then I'd definitely go for a DVCS such as git, mercurial or bzr.
Driving down the cost of branching is very liberating in terms of
doing short spikes to try out ideas, but it can be a personal thing
based on your own workflow. If you did choose Subversion, I think
someone in the community could setup something on github to pull it
from Subversion anyway - I know several projects such as JRuby use
Subversion on codehaus, but there are lots of git repositories based
off the Subversion copy, for people to try out ideas and share them
without necessarily having commit access to Subversion.

Mercurial does have a plugin for Eclipse as well, so tool support is
getting there.

Yahoo Groups already has the mailing list, so the idea of using
separate providers already seems to be implicitly there, but I just
wanted to draw it out a little.

Cheers,

James

2008/12/10 David Saff <david@...>:
> I think we'd be hard-pressed to find another hosting solution that feels as
> bulky as SourceForge. I also think it's easy to over-state JUnit's
> importance to a hosting provider: as far as I know, we've never cracked the
> top 50 projects at SourceForge--we release rather infrequently, and many,
> many people get JUnit for free with Eclipse, maven, etc.
>
> David Saff
>
> On Wed, Dec 10, 2008 at 12:59 PM, Joakim Ohlrogge <joakim.ohlrogge@...
>> wrote:
>
>> I know sharesource http://www.sharesource.org hosts both mercurial and
>> SVN, I'm not sure whether the same source can be accessed in both ways
>> or not. We are using mercurial at my company and it works well on both
>> windox, linux and mac. What is mainly lacking is good ide support but
>> I say that netbeans support mercurial natively now so maybe that is
>> worth a try.
>>
>> Sharesource does not seem to have any export restrictions but is
>> lacking review features as far as I know. But it has this certain warm
>> fuzzy family "niceness" to it and does not feel as big and bulky as
>> sourceforge does. I felt had to mention sharesource because I like it,
>> I also think that whatever is lacking in features would be looked into
>> in order to accomodate such a well known project such as JUnit, but
>> thats just how I reasoning if I was running sharesource :)
>>
>
>>
>>
>> In my book a distributed vcs such as Git, mercurial or bazaar would be
>> a big plus.
>> /J
>>
>>
>> On Tue, Dec 9, 2008 at 8:24 PM, mark_p_thornton
>> <mark.p.thornton@... <mark.p.thornton%40ntlworld.com>> wrote:
>> > --- In junit@yahoogroups.com <junit%40yahoogroups.com>, "Nat Pryce"
>> <nat.pryce@...> wrote:
>> >>
>> >> 2008/12/8 Shane Mingins <shane.mingins@...>:
>> >
>> >> > Have you considered git and github ... just as a thought?
>> >> >
>> >> > http://github.com/
>> >> >
>> >> > Not sure how that fits in the Java space or not.
>> >>
>> >> It's more of a problem for people working on Windows. As far as I
>> >> know, the only DVCS that works well on Windows is Bazaar.
>> >>
>> >
>> > Mercurial also works well on Windows --- one of the reasons why it is
>> > now used by Sun for the OpenJDK.
>> >
>> >
>>
>> --
>> -----------------------------------------------------
>> Joakim Ohlrogge
>> Agical AB
>> Västerlånggatan 79, 2 tr
>> 111 29 Stockholm, SWEDEN
>>
>> Mobile: +46-708-754004
>> Blog: johlrogge.wordpress.com
>> E-mail: joakim.ohlrogge@... <joakim.ohlrogge%40agical.se>
>>
>>
>
> [Non-text portions of this message have been removed]
>
>

John,

What you can do is to rely on spring and
AbstractDependencyInjectionSpringContextTest (ugh !) in order to inject, via
spring, your interface's implementation.

A piece of example (let's assume MyConcreteClass implements MyInterface) :

public class MyTest extends AbstractDependencyInjectionSpringContextTest {

     private MyInterface foo;

     public void MyTest(String name){
         super(name);
         setAutowireMode(AUTOWIRE_BY_NAME); // Activating spring autowiring :
foo will be automatically injected via spring before test is run
     }

     // provide a "public" foo setter, in order to allow spring to autowire
it
     public void setFoo(MyInterface foo){ this.foo = foo; }

     public void testInjection(){
         assertNotNull(foo);
         assertEquals(0, foo.size());
         foo.add("Hello");
         assertEquals(1, foo.size());
     }
}

Your spring xml file will be like the following :
<beans>
     <bean id="foo" class="MyConcreteClass" />
</beans>

Hope this helps
Frédéric

2008/12/11 John <john_roshi@...>

>   --- In junit@yahoogroups.com <junit%40yahoogroups.com>, "lancezant"
> <lance.zant@...> wrote:
>
> > The crux of the problem is that the base tests need a way to
> > instantiate the class under test without knowing what class that is.
>
> That's EXACTLY where I was stuck.
>
> > To do this, the base test class relied on an abstract factory method
> > implemented in each concrete test class according to the target
> > implementation.
>
> Aha! Let me try that, thanks.
>
> --john
>
>
>



--
Frédéric Camblor


[Non-text portions of this message have been removed]

A JUnit parameterised test would be significantly simpler.

--Nat

2008/12/11 Frédéric Camblor <fcamblor@...>:
> John,
>
> What you can do is to rely on spring and
> AbstractDependencyInjectionSpringContextTest (ugh !) in order to inject, via
> spring, your interface's implementation.
>
> A piece of example (let's assume MyConcreteClass implements MyInterface) :
>
> public class MyTest extends AbstractDependencyInjectionSpringContextTest {
>
> private MyInterface foo;
>
> public void MyTest(String name){
> super(name);
> setAutowireMode(AUTOWIRE_BY_NAME); // Activating spring autowiring :
> foo will be automatically injected via spring before test is run
> }
>
> // provide a "public" foo setter, in order to allow spring to autowire
> it
> public void setFoo(MyInterface foo){ this.foo = foo; }
>
> public void testInjection(){
> assertNotNull(foo);
> assertEquals(0, foo.size());
> foo.add("Hello");
> assertEquals(1, foo.size());
> }
> }
>
> Your spring xml file will be like the following :
> <beans>
> <bean id="foo" class="MyConcreteClass" />
> </beans>
>
> Hope this helps
> Frédéric
>
> 2008/12/11 John <john_roshi@...>
>
>> --- In junit@yahoogroups.com <junit%40yahoogroups.com>, "lancezant"
>
>> <lance.zant@...> wrote:
>>
>> > The crux of the problem is that the base tests need a way to
>> > instantiate the class under test without knowing what class that is.
>>
>> That's EXACTLY where I was stuck.
>>
>> > To do this, the base test class relied on an abstract factory method
>> > implemented in each concrete test class according to the target
>> > implementation.
>>
>> Aha! Let me try that, thanks.
>>
>> --john
>>
>>
>>
>
> --
> Frédéric Camblor
>
> [Non-text portions of this message have been removed]
>
>



--
http://www.natpryce.com

http://c2.com/cgi/wiki?AbstractTest

2008/12/11 John <john_roshi@...>:
> --- In junit@yahoogroups.com, "lancezant" <lance.zant@...> wrote:
>
>> The crux of the problem is that the base tests need a way to
>> instantiate the class under test without knowing what class that is.
>
> That's EXACTLY where I was stuck.
>
>> To do this, the base test class relied on an abstract factory method
>> implemented in each concrete test class according to the target
>> implementation.
>
> Aha! Let me try that, thanks.
>
> --john
>
>

Hi.

I'm in a project which puts unit tests in their normal package tree
(com.company.division.softwaresuite.part.really.long) and integration
tests in another package tree (itest.com.company.division....). This
is all well with maven but when I try to execute all JUnit tests under
com.company-branch via right click -> Run as in the Package Explorer
view (Java perspective), I get a "Problems Launching JUnit Tests: No
tests found with test runner 'JUnit 4'". The same happens when I focus
the itest.com.company-branch.

I've tried to find settings for the JUnit plug-in (JUnit Testing
Framework Version 4, 4.3.1, org.junit4) in Eclipse (3.4.0) but can't
find anything useful.

Any pointers or hints on what to do is highly appreciated.

/ Fredrik Wendt

Fredrik,

If you right-click the individual classes and Run As... JUnit Test, do they
run?

    David Saff

On Mon, Dec 15, 2008 at 8:45 AM, Fredrik Wendt <fredrik@...> wrote:

>   Hi.
>
> I'm in a project which puts unit tests in their normal package tree
> (com.company.division.softwaresuite.part.really.long) and integration
> tests in another package tree (itest.com.company.division....). This
> is all well with maven but when I try to execute all JUnit tests under
> com.company-branch via right click -> Run as in the Package Explorer
> view (Java perspective), I get a "Problems Launching JUnit Tests: No
> tests found with test runner 'JUnit 4'". The same happens when I focus
> the itest.com.company-branch.
>
> I've tried to find settings for the JUnit plug-in (JUnit Testing
> Framework Version 4, 4.3.1, org.junit4) in Eclipse (3.4.0) but can't
> find anything useful.
>
> Any pointers or hints on what to do is highly appreciated.
>
> / Fredrik Wendt
>
>
>


[Non-text portions of this message have been removed]

mån 2008-12-15 klockan 11:38 -0500 skrev David Saff:
> Fredrik,
>
> If you right-click the individual classes and Run As... JUnit Test, do they
> run?

Yes.

src/test/java (runs seven classes' tests)
   com.company.package [NOT HERE]
     subpack1 (runs two classes' tests)
       TestClass1
       TestClass2
     subpack2 (runs one classes' tests)
       TestClass3
   itest.com.company.package [NOT HERE]
     subpack1 (runs two classes' tests)
       IntegrationTestClass1
       IntegrationTestClass2
     subpack2 (runs two classes' tests)
       IntegrationTestClass3
       IntegrationTestClass4

In the tree above - I can start a run from any point except those marked
with [NOT HERE].

My problem, from what I can tell right now, is that the plug-in from
Eclipse is to shallow - I'd like it to look into it's sub packages and
look for tests there too.

I guess we could use the DirectorySuiteBuilder as described in the FAQ*
and put a class at

com.company.package and
itest.com.company.package

in every eclipse project/mvn module. That would be 16 files ... Perhaps
looking into the Eclipse plug-in isn't such a bad idea (though I guess
it'll take longer to add the feature, package the plug-in and get it
properly into all team members' Eclipse installation).

/
	 Fredrik

* http://junit.sourceforge.net/doc/faq/faq.htm#running_15


[Non-text portions of this message have been removed]

Hi,
 
i need to run my junit test case(for GUI application) from command line, can
anyone help me on this issue.
 
Thanks in Advance
Shankar




[Non-text portions of this message have been removed]

Hello,
I have javascript tests taht execute in a browser page and I would
like to include those tests in standard test results the build tool
(maven) provides. So I am trying to write a JUnit 4 test wrapper that
would do the following:
  - launch the tests within the context of a real or fake browser
  - gather test results from the HTML pages
  - generate junit test results

In Junit 3, I would write a dedicated suite() method in some class and
use the TestResult object that would be populated by my suite method.
I am not sure how to do this in JUnit 4. I was about to implement a
dedicated Runner but is this not overkill ?

Maybe there is a  very simple solution to this problem I am not aware of.

Thanks in advance
Arnaud Bailly

Hi, after a long absence, I'm getting back into using Java and JUnit.
I'm in the process of bringing our old JUnit 3 test set to JUnit 4.5.
In the JUnit 3 days, we used Gargoyle Software's RecursiveTestSuite to
build a suite from all test case classes in our project.  It would just
recurse down a directory tree, find .class files, and build a suite from
them.  Now I need to find a suitable JUnit 4 way of doing that.  Does
anyone have an equivalent?


Thanks,
Todd.
----
Todd Bradley - Polycom, Inc.
ReadiVideo QA Lead

Todd,

You can search for cpsuite.  Last I checked, it needed a little massaging to
work with 4.5, but it made me happy.

    David Saff

On Mon, Dec 15, 2008 at 6:50 PM, Bradley, Todd <todd.bradley@...>wrote:

>   Hi, after a long absence, I'm getting back into using Java and JUnit.
> I'm in the process of bringing our old JUnit 3 test set to JUnit 4.5.
> In the JUnit 3 days, we used Gargoyle Software's RecursiveTestSuite to
> build a suite from all test case classes in our project. It would just
> recurse down a directory tree, find .class files, and build a suite from
> them. Now I need to find a suitable JUnit 4 way of doing that. Does
> anyone have an equivalent?
>
> Thanks,
> Todd.
> ----
> Todd Bradley - Polycom, Inc.
> ReadiVideo QA Lead
>
>
>


[Non-text portions of this message have been removed]