On Fri, Nov 20, 2009 at 10:07 PM, Georg <le_garcon_enerve@...> wrote:
> Hi David,
>
> Did you gave thoughs to cases where one would like to exclude certain tests?
E.g.: run all  tests that are not in (a) certain category(s)? This is probably
not difficult add in one way or another onto the concept of categories, but the
answer to "which test is now acctually included" could become confusing in cases
where a test is in an included and an excluded category. I would like to see
something here that does not require a lot of browsing through hierarchies of
suites nad categories. This may in my approach not well solved either as suites
can extend on other suites: if a referenced suite includes a certain test, it is
executed even if the extending suite excludes a test.

Georg,

We came very close to adding an ExcludeCategories annotation.
However, we decided to stay at a minimal feature set for Categories in
the initial release, figuring that if the whole API turned out to be
wrong, or if users just shrugged, then any time put into perfecting
the mini-language of category filter configuration would be wasted.
If the feature takes off, I think we'll certainly revisit that
decision (especially if a highly-voted github issue requests it, hint,
hint.)

However, Iyou touch on another concern: a simple category feature set
that is easy to understand, but leaves out 20% of valid use cases, may
be preferable to a more "feature complete" feature implementation that
requires pages of documentation to fully grok.  I don't know that
we're in danger of either extreme yet.

    David Saff

>
> And more fundamentally: is the idea/need of exclusion meaningfull or just a
result of badly organising tests (I'd say no, but I may be wrong)?
>
> Cheers,
>  Georg
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

2009/11/20 CĂ©dric Beust â™” <cbeust@...>:
> On Fri, Nov 20, 2009 at 7:07 PM, Georg <le_garcon_enerve@...> wrote:
>
>>
>>
>> Hi David,
>>
>> Did you gave thoughs to cases where one would like to exclude certain
>> tests? E.g.: run all tests that are not in (a) certain category(s)? This is
>> probably not difficult add in one way or another onto the concept of
>> categories, but the answer to "which test is now acctually included" could
>> become confusing in cases where a test is in an included and an excluded
>> category. I would like to see something here that does not require a lot of
>> browsing through hierarchies of suites nad categories. This may in my
>> approach not well solved either as suites can extend on other suites: if a
>> referenced suite includes a certain test, it is executed even if the
>> extending suite excludes a test.
>>
>> And more fundamentally: is the idea/need of exclusion meaningfull or just a
>> result of badly organising tests (I'd say no, but I may be wrong)?
>>
>
> For what it's worth, excluding tests is a very popular TestNG features.  For
> example, I use it when a few tests are broken and need to remain so for a
> while:  I put them in the group "broken", which I always exclude during my
> runs.
>
> When the time to ship approaches, I look at all the tests in the "broken"
> category and I go fix them then.

For this particular use case, I've found @Ignore generally useful.  I
also really love Kevin Lawrence's idea of marking tests with bug
numbers.  He does it like this:

@Test public void shouldntDeleteAllTheUsersFiles() {
   bug(34456);
   ...
}

The test only starts failing once bug 34456 is marked as fixed in the
bug system.  Once we have failing assumptions working as they truly
should, this will be easy to implement on the JUnit side, although the
bug-system integration would still be up to individual extenders or
teams.

All this is to say that I do get the idea of excluded categories, but
this particular instance doesn't immediately convince me.

    David Saff

>
> --
> ***CĂ©dric
> *
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Hi David!

A minor thing: why did you decide to use an additional annotation and did not
add a property to @SuiteClasses?

E.g., your example (on
http://saffgreenbar.blogspot.com/2009/11/heres-test-code-snippet-public.html)


@RunWith(Categories.class)
  @IncludeCategory(SlowTests.class)
  @SuiteClasses( { A.class, B.class, C.class })
  public static class SlowTestSuite {
  }

could read

@RunWith(Suite.class)
  @SuiteClasses( { A.class, B.class, C.class },
   categories={SlowTests.class})
  public static class SlowTestSuite {
}

This would make it more visible which tests a suite includes and reduces the
number of annotations.

Regards,
    Georg

Hello,

I use junit 4.4 and there is no chance to use a newer version of junit.

I have a TestListener which extends RunListener.

I overwrite the methode testStarted(Description).

Is there a chance to get the testclass from this description. I mean an instance
of this class or the reference of the instance of the class.

I need this because the test class conists a annotation, which descripes the
testgroup. And I want to get the value of this annotation. Therefor I need a
instance of the testclass.

I know that there is a methode getAnnotation(). But with this methode I get only
the annotation tfrom the test methode and not from the test class.

How can I realize it, that I get the annotation for the class?

I second that the @Ignore is the way to go with this. What I do is define some
String constants in a relevant class that defines the basic reasons (read
Categories) of things that are ignored, so I can do a where-used with my IDE to
find which tests are ignored under that category. (Not that I have to do it that
often, but I found the approach gives me everything I need).

Yishai

--- In junit@yahoogroups.com, David Saff <david@...> wrote:
>
> 2009/11/20 CĂ©dric Beust â™" <cbeust@...>:
> > On Fri, Nov 20, 2009 at 7:07 PM, Georg <le_garcon_enerve@...> wrote:
> >
> >>
> >>
> >> Hi David,
> >>
> >> Did you gave thoughs to cases where one would like to exclude certain
> >> tests? E.g.: run all tests that are not in (a) certain category(s)? This is
> >> probably not difficult add in one way or another onto the concept of
> >> categories, but the answer to "which test is now acctually included" could
> >> become confusing in cases where a test is in an included and an excluded
> >> category. I would like to see something here that does not require a lot of
> >> browsing through hierarchies of suites nad categories. This may in my
> >> approach not well solved either as suites can extend on other suites: if a
> >> referenced suite includes a certain test, it is executed even if the
> >> extending suite excludes a test.
> >>
> >> And more fundamentally: is the idea/need of exclusion meaningfull or just a
> >> result of badly organising tests (I'd say no, but I may be wrong)?
> >>
> >
> > For what it's worth, excluding tests is a very popular TestNG features.
 For
> > example, I use it when a few tests are broken and need to remain so for a
> > while:  I put them in the group "broken", which I always exclude during my
> > runs.
> >
> > When the time to ship approaches, I look at all the tests in the "broken"
> > category and I go fix them then.
>
> For this particular use case, I've found @Ignore generally useful.  I
> also really love Kevin Lawrence's idea of marking tests with bug
> numbers.  He does it like this:
>
> @Test public void shouldntDeleteAllTheUsersFiles() {
>   bug(34456);
>   ...
> }
>
> The test only starts failing once bug 34456 is marked as fixed in the
> bug system.  Once we have failing assumptions working as they truly
> should, this will be easy to implement on the JUnit side, although the
> bug-system integration would still be up to individual extenders or
> teams.
>
> All this is to say that I do get the idea of excluded categories, but
> this particular instance doesn't immediately convince me.
>
>    David Saff
>
> >
> > --
> > ***CĂ©dric
> > *
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

For what it is worth, I would prefer the separate annotation, as it makes it
more feasible to use it with other runners.

Yishai

--- In junit@yahoogroups.com, "Georg" <le_garcon_enerve@...> wrote:
>
>
> Hi David!
>
> A minor thing: why did you decide to use an additional annotation and did not
add a property to @SuiteClasses?
>
> E.g., your example (on
http://saffgreenbar.blogspot.com/2009/11/heres-test-code-snippet-public.html)
>
>
> @RunWith(Categories.class)
>  @IncludeCategory(SlowTests.class)
>  @SuiteClasses( { A.class, B.class, C.class })
>  public static class SlowTestSuite {
>  }
>
> could read
>
> @RunWith(Suite.class)
>  @SuiteClasses( { A.class, B.class, C.class },
>   categories={SlowTests.class})
>  public static class SlowTestSuite {
> }
>
> This would make it more visible which tests a suite includes and reduces the
number of annotations.
>
> Regards,
>    Georg
>

On Sun, Nov 22, 2009 at 9:36 AM, yme0987654321 <yme0987654321@...>wrote:

>
>
> I second that the @Ignore is the way to go with this.
>
The problem with @Ignore is that 1) you need to specify it on all the
methods you want to exclude and 2) it forces a recompilation.

Being able to specify "-ignore broken" at runtime allows you to exclude
dozens of methods in one single command.

--
***Cédric
*


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

2009/11/22 CĂ©dric Beust â™” <cbeust@...>:
> On Sun, Nov 22, 2009 at 9:36 AM, yme0987654321 <yme0987654321@...>wrote:
>
>>
>>
>> I second that the @Ignore is the way to go with this.
>>
> The problem with @Ignore is that 1) you need to specify it on all the
> methods you want to exclude and 2) it forces a recompilation.
>
> Being able to specify "-ignore broken" at runtime allows you to exclude
> dozens of methods in one single command.

This story makes sense to me if you have many tests in the broken
group, and sometimes want to run all of them, and sometimes want to
run none of them.  Is that your frequent experience?  If so, I agree
that excludable categories would be the way to do it.

In my frequent experience, I tend to never run all the tests in the
"broken" set: I enable them one by one, and fix them, when I can, so
@Ignore works fine for me.

    David Saff

>
> --
> ***CĂ©dric
> *
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

On Sun, Nov 22, 2009 at 7:36 PM, David Saff <david@...> wrote:

>
> > The problem with @Ignore is that 1) you need to specify it on all the
> > methods you want to exclude and 2) it forces a recompilation.
> >
> > Being able to specify "-ignore broken" at runtime allows you to exclude
> > dozens of methods in one single command.
>
> This story makes sense to me if you have many tests in the broken
> group, and sometimes want to run all of them, and sometimes want to
> run none of them. Is that your frequent experience? If so, I agree
> that excludable categories would be the way to do it.
>

No, I never really run all the methods in the excluded groups, most of the
time, their purpose is just to be excluded.  When I want to start fixing the
broken tests, I look at all the tests in that group and I take them out of
it one by one as I fix them.

But group exclusion has other uses, such as "running all the tests except
the slow ones", "excluding the ui tests", "excluding the Linux tests",
etc...

Admittedly, this is more on the integration/functional than on the unit test
side, so you might consider these out of scope for JUnit.


> In my frequent experience, I tend to never run all the tests in the
> "broken" set: I enable them one by one, and fix them, when I can, so
> @Ignore works fine for me.
>

That's also my experience for the Broken category.

--
***Cédric
*


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

2009/11/22 CĂ©dric Beust â™” <cbeust@...>:
> On Sun, Nov 22, 2009 at 7:36 PM, David Saff <david@...> wrote:
>
>>
>> > The problem with @Ignore is that 1) you need to specify it on all the
>> > methods you want to exclude and 2) it forces a recompilation.
>> >
>> > Being able to specify "-ignore broken" at runtime allows you to exclude
>> > dozens of methods in one single command.
>>
>> This story makes sense to me if you have many tests in the broken
>> group, and sometimes want to run all of them, and sometimes want to
>> run none of them. Is that your frequent experience? If so, I agree
>> that excludable categories would be the way to do it.
>>
>
> No, I never really run all the methods in the excluded groups, most of the
> time, their purpose is just to be excluded.  When I want to start fixing the
> broken tests, I look at all the tests in that group and I take them out of
> it one by one as I fix them.
>
> But group exclusion has other uses, such as "running all the tests except
> the slow ones", "excluding the ui tests", "excluding the Linux tests",
> etc...
>
> Admittedly, this is more on the integration/functional than on the unit test
> side, so you might consider these out of scope for JUnit.

Got it.  So we seem in agreement that excluded categories may be
useful, but a "broken" category is not the best argument for them.

    David Saff

>
>
>> In my frequent experience, I tend to never run all the tests in the
>> "broken" set: I enable them one by one, and fix them, when I can, so
>> @Ignore works fine for me.
>>
>
> That's also my experience for the Broken category.
>
> --
> ***CĂ©dric
> *
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Unfortunately, I don't know of a way to do that easily in any JUnit
class.  There's two possibilities I could think of as workarounds:

1) You can usually parse the class name from the description, and then
load the class
2) The testRunStarted event contains the top-level description for the
whole test run--you could descend this, and construct a map from
leaves to parents.

Neither is great.  If you ever might have a chance to upgrade, please
do submit a feature request at http://github.com/KentBeck/junit/issues

Thanks,

   David

On Sun, Nov 22, 2009 at 10:05 AM, eclipse.beginner
<eclipse.beginner@...> wrote:
> Hello,
>
> I use junit 4.4 and there is no chance to use a newer version of junit.
>
> I have a TestListener which extends RunListener.
>
> I overwrite the methode testStarted(Description).
>
> Is there a chance to get the testclass from this description. I mean an
instance of this class or the reference of the instance of the class.
>
> I need this because the test class conists a annotation, which descripes the
testgroup. And I want to get the value of this annotation. Therefor I need a
instance of the testclass.
>
> I know that there is a methode getAnnotation(). But with this methode I get
only the annotation tfrom the test methode and not from the test class.
>
> How can I realize it, that I get the annotation for the class?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

All,

I believe that all owners of items on the SourceForge trackers have
been notified to move their items over to the GitHub tracker:

http://github.com/KentBeck/junit/issues

I've hidden the main browse pages for these trackers, as well, to
encourage people to go to the right place (there's still better
communication that can be done here).

If you have a request or bug with JUnit that's not in the GitHub issue
tracker, please add it.  Remember that we take vote counts seriously
when prioritizing work.  Thanks,

    David Saff

I absolutely second this!

Georg

Georg,

Unfortunately, your context got snipped: are you seconding the
original Categories feature as presented, or one of the follow-on
proposals later in the thead?  Thanks,

    David Saff

On Mon, Nov 23, 2009 at 11:37 AM, Georg <le_garcon_enerve@...> wrote:
>
> I absolutely second this!
>
> Georg
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

No idea!  I didn't think negative votes were possible.  I've voted it
up to 0, and I'll ping the github administrators to see what's going
on.  Sorry...

    David Saff

On Mon, Nov 23, 2009 at 9:34 AM, David Saff <david@...> wrote:
> All,
>
> I believe that all owners of items on the SourceForge trackers have
> been notified to move their items over to the GitHub tracker:
>
> http://github.com/KentBeck/junit/issues
>
> I've hidden the main browse pages for these trackers, as well, to
> encourage people to go to the right place (there's still better
> communication that can be done here).
>
> If you have a request or bug with JUnit that's not in the GitHub issue
> tracker, please add it.  Remember that we take vote counts seriously
> when prioritizing work.  Thanks,
>
>   David Saff
>

Hello!

you can also use Runtime.getRuntime().registerShutdownHook(...) to
register a shutdown-hook that is run after junit is done. But I don't
hink you can throw assertion errors in the shutdown hook.

Another idea would be to capture System.out or the logging-stream and
verify in your tests, that no exception is in the log/out-stream, as
this is (from what I understood) closer to what you really want to
test for.

I do the runBefore the same way as you said. The only difference: I
put the init-code as @BeforeClass in a superclass and my tests simply
inherit from it.

When you use eclipse, you probably don't build explicit suites, so you
can't use @BeforeClass and @AfterClass on a suite easily.
This would work with
@RunWith(Suite.class)
@SuiteClasses({Class1.class, Class2.class, ....})
public void AllTests {
@BeforeClass
public static void runBeforeAllTests() {
}

@AfterClass
public static void runAfterAllTests() {
}
}

You could look into cpSuite, which allows this, I think, and still
runs all tests automatically.

Greetings,
    Malte

2009/11/19 stolsvik <online@...>:
> I need some way to run a certain test after all other tests.
>
> I run my tests in Eclipse, and do not yet have a build system outside of it. I
understand that had I done this programmatically, I could have attached a
RunListener, implementing the testRunFinished(Result) method.
>
> Is there any way to achieve a similar effect within the JUnit runner in
Eclipse?
>
> Rationale: I have actual unit tests, then bigger tests, then full-fledged
"integration tests" or whatever one call them, where I take up my entire
application-local server thingy and process a bunch of items, letting JUnit
check after the dust settles whether the items was processed correctly. However,
the internals are multi threaded, and also, this being a Swing app, lots of
Runnables are sent over to the EDT. This is all good.
>
> However, I've sometimes seen that a thread crashes (uncaught exception),
without this being noticed by any of the tests running (I've e.g. seen a
ConcurrentModificationException take down the EDT, without having a clue as to
why I got that - and the next event posted just brings up a new EDT, so I get a
green bar, but with an uncaught error). What I'd want to achieve, is to install
an uncaught exception handler, and then, as a final step to ALL permutations of
tests (e.g. both for a single unit test, and also for the project-wide test
run), run a test that checks whether any thread-killing exception was caught by
the handler, and if so, fails the run. (I'd throw the exception that was caught,
and in any case also log-dump any and all such exceptions).
>
> (As a very similar question, I'd also like to have a "before any tests" thing,
like the RunListener.testRunStarted(Description) method, where I could set up
logging. Now I do that by letting ALL tests have a static block that calls a
specific static method which has a static boolean that tells whether the log
system already is set up. This also works just nicely, but is a hassle
nevertheless. However, it is not possible, as I see it, to solve the above
question in the same manner.)
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

All,

HEAD on github has two enhancements to the original category proposal:
any class can be a category marker, and categories can be excluded
from suites.  I'll try to put together a more comprehensive release
note soon.

    David Saff

Hello All!

I'm using JUnit 4.5 and I'm facing a problem with the EDT.
I'm wondering if there is an easy way to create a custom Runner that will run my
UI tests in the EDT. I did find just one example in the Internet that played
with org.junit.internal and I would like to get to a more stable solution.
I know I could make every assertion with Runnables and
SwingUtilities.invokeAndWait(), but I feel the code gets messy.
I am dreaming with JUnit providing a runner for the EDT :) but in the meantime:
Has anyone faced this problem before? If so, how did you solve it? :)
Thanks!

Marcelo.

Ps: In this project the would not let me use Jemmy or Fest, so I am stuck.

Hi Marcelo,

What is the problem you are facing? Only access to Swing components needs to be
done in the EDT, not the whole test.

If you cannot use FEST, simply copy the source (3 or 4 small classes) in the
package org.fest.swing.edt. The license is Apache 2.0 (business friendly,) so
you can use the code as you wish.

I wrote a little blog entry about writing EDT-safe tests. You can find it at
http://alexruiz.developerblogs.com/?p=160 . I hope that helps :)

Cheers,
-Alex

--- On Tue, 11/24/09, marcelo_javier_ruiz <marcelo_javier_ruiz@...>
wrote:

From: marcelo_javier_ruiz <marcelo_javier_ruiz@...>
Subject: [junit] Event Dispatch Thread
To: junit@yahoogroups.com
Date: Tuesday, November 24, 2009, 10:08 PM







 









       Hello All!



I'm using JUnit 4.5 and I'm facing a problem with the EDT.

I'm wondering if there is an easy way to create a custom Runner that will run my
UI tests in the EDT. I did find just one example in the Internet that played
with org.junit.internal and I would like to get to a more stable solution.

I know I could make every assertion with Runnables and SwingUtilities.
invokeAndWait( ), but I feel the code gets messy.

I am dreaming with JUnit providing a runner for the EDT :) but in the meantime:
Has anyone faced this problem before? If so, how did you solve it? :)

Thanks!



Marcelo.



Ps: In this project the would not let me use Jemmy or Fest, so I am stuck.

























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

Hi  David!

I meant to second your statement
#  Got it. So we seem in agreement that excluded categories may be

#  useful, but a "broken" category is not the best argument for them.

Regards,
 Georg








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

Hi Alex!

Thank for the quick reply. The problem I was facing was because we're
using Mockito, and it does not support mock setting and verification by
different threads. I will take a look to your code, but in the meantime
I found a solution (and EDT Runner for JUnit 4.5) that I will share just
in case someone else needs this weird trick:

import javax.swing.SwingUtilities;
import org.junit.Ignore;
import org.junit.runner.notification.RunNotifier;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;
import org.junit.runners.model.Statement;


/**
   * Runs JUnit tests in the Event Dispatch Thread (EDT).
   *
   * To accomplish this, timeouts are not considered.
   * @BeforeClass and @AfterClass methods are NOT run in the EDT
   *
   * @author Marcelo J. Ruiz.
   */
@Ignore
public class EDTRunner extends org.junit.runners.BlockJUnit4ClassRunner
{

      public SwingRunner(Class<?> klass) throws InitializationError {
          super(klass);
      }

      @Override
      protected void runChild(final FrameworkMethod method,
              final RunNotifier notifier) {

          try {
              SwingUtilities.invokeAndWait(new Runnable() {

                  @Override
                  public void run() {
                      hookMethod(method, notifier);
                  }
              });
          } catch (Exception ex) {
              throw new RuntimeException(
                      "Failed While Running in EDT:" + ex.getMessage(),
                      ex);
          }
      }

      private void hookMethod(final FrameworkMethod method,
              final RunNotifier notifier) {
          super.runChild(method, notifier);
      }

      @Override
      protected Statement withPotentialTimeout(final FrameworkMethod
method,
              final Object test, final Statement next) {
          return next;
      }
}

Thanks again Alex!

Marcelo

--- In junit@yahoogroups.com, "marcelo_javier_ruiz"
<marcelo_javier_ruiz@...> wrote:
>
> Hello All!
>
> I'm using JUnit 4.5 and I'm facing a problem with the EDT.
> I'm wondering if there is an easy way to create a custom Runner that
will run my UI tests in the EDT. I did find just one example in the
Internet that played with org.junit.internal and I would like to get to
a more stable solution.
> I know I could make every assertion with Runnables and
SwingUtilities.invokeAndWait(), but I feel the code gets messy.
> I am dreaming with JUnit providing a runner for the EDT :) but in the
meantime: Has anyone faced this problem before? If so, how did you solve
it? :)
> Thanks!
>
> Marcelo.
>
> Ps: In this project the would not let me use Jemmy or Fest, so I am
stuck.
>



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

Hi all,

I have this situation:
A big interface "I" which is implemented by the "A" and "B" classes.

I've solved the problem of wrote only one test for both implementations using
the method described here:

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

So I have an abstract class "T" with all methods test for "I" annotated as JUnit
4 specify, then I instantiate "T" passing "A" or "B" instance.


Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I
want to collect it under a common test suite "TS".

I have tried this solution:
"TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to
the test suite.
But this solution don't work because "T1" need to extend TestCase and in "T1"
I'm using JUnit 4 annotations.

Any idea how to solve the problem?

Thanks
Federico

I just posted some sample code about this topic on my blog.

It will be a more polished response in the future, but for now take a look.

http://bigmikef.blogspot.com/2009/11/reply-to-junit-mailing-list-about.html

Big Mike

On Thu, Nov 26, 2009 at 2:23 PM, Mike Forsberg <bigmike@...> wrote:
> I wonder why you are extending TestCase if you are using annotations?
> Extending the TestCase class is the old 3.x way of doing things.  Now,
> you only need to implement a method and annotate it with @Test to make
> a test method.
>
> Also I don't know why you are constructing instances of the tests...
>
> If you'd like more help I'll write up a snippet of code and post it to
> the mailing list.
>
> Big Mike
>
> On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
>> Hi all,
>>
>> I have this situation:
>> A big interface "I" which is implemented by the "A" and "B" classes.
>>
>> I've solved the problem of wrote only one test for both implementations using
the method described here:
>>
>> http://c2.com/cgi/wiki?AbstractTestCases
>>
>> So I have an abstract class "T" with all methods test for "I" annotated as
JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
>>
>>
>> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I
want to collect it under a common test suite "TS".
>>
>> I have tried this solution:
>> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to
the test suite.
>> But this solution don't work because "T1" need to extend TestCase and in "T1"
I'm using JUnit 4 annotations.
>>
>> Any idea how to solve the problem?
>>
>> Thanks
>> Federico
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>

I wonder why you are extending TestCase if you are using annotations?
Extending the TestCase class is the old 3.x way of doing things.  Now,
you only need to implement a method and annotate it with @Test to make
a test method.

Also I don't know why you are constructing instances of the tests...

If you'd like more help I'll write up a snippet of code and post it to
the mailing list.

Big Mike

On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
> Hi all,
>
> I have this situation:
> A big interface "I" which is implemented by the "A" and "B" classes.
>
> I've solved the problem of wrote only one test for both implementations using
the method described here:
>
> http://c2.com/cgi/wiki?AbstractTestCases
>
> So I have an abstract class "T" with all methods test for "I" annotated as
JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
>
>
> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I
want to collect it under a common test suite "TS".
>
> I have tried this solution:
> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to
the test suite.
> But this solution don't work because "T1" need to extend TestCase and in "T1"
I'm using JUnit 4 annotations.
>
> Any idea how to solve the problem?
>
> Thanks
> Federico
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--- In junit@yahoogroups.com, Mike Forsberg <bigmike@...> wrote:
>
> I wonder why you are extending TestCase if you are using annotations?
> Extending the TestCase class is the old 3.x way of doing things.


I needed it to put my test classes into a testsuite. The addTest method accept
only Test interface implementations.


  Now,
> you only need to implement a method and annotate it with @Test to make
> a test method.
>
> Also I don't know why you are constructing instances of the tests...

For pass it the Interface implementation to test.

>
> If you'd like more help I'll write up a snippet of code and post it to
> the mailing list.
>
> Big Mike

I think your article is OK.

Thanks
Federico


>
> On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
> > Hi all,
> >
> > I have this situation:
> > A big interface "I" which is implemented by the "A" and "B" classes.
> >
> > I've solved the problem of wrote only one test for both implementations
using the method described here:
> >
> > http://c2.com/cgi/wiki?AbstractTestCases
> >
> > So I have an abstract class "T" with all methods test for "I" annotated as
JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
> >
> >
> > Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I
want to collect it under a common test suite "TS".
> >
> > I have tried this solution:
> > "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances
to the test suite.
> > But this solution don't work because "T1" need to extend TestCase and in
"T1" I'm using JUnit 4 annotations.
> >
> > Any idea how to solve the problem?
> >
> > Thanks
> > Federico
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

Hi Big Mike,
thanks for your article. Your solution is for sure an answer to my problem.

There is an aspect that I don't like, with that solution I need to instantiate
an interface implementation ("A","B".. classes) for each test class. That was
the reason why I was trying to put all test classes in a test suite, anyway this
is not a big problem.

Thanks.
Federico




--- In junit@yahoogroups.com, Mike Forsberg <bigmike.f@...> wrote:
>
> I just posted some sample code about this topic on my blog.
>
> It will be a more polished response in the future, but for now take a look.
>
> http://bigmikef.blogspot.com/2009/11/reply-to-junit-mailing-list-about.html
>
> Big Mike
>
> On Thu, Nov 26, 2009 at 2:23 PM, Mike Forsberg <bigmike@...> wrote:
> > I wonder why you are extending TestCase if you are using annotations?
> > Extending the TestCase class is the old 3.x way of doing things.  Now,
> > you only need to implement a method and annotate it with @Test to make
> > a test method.
> >
> > Also I don't know why you are constructing instances of the tests...
> >
> > If you'd like more help I'll write up a snippet of code and post it to
> > the mailing list.
> >
> > Big Mike
> >
> > On Thu, Nov 26, 2009 at 3:11 AM, Fedy2 <fedy2@...> wrote:
> >> Hi all,
> >>
> >> I have this situation:
> >> A big interface "I" which is implemented by the "A" and "B" classes.
> >>
> >> I've solved the problem of wrote only one test for both implementations
using the method described here:
> >>
> >> http://c2.com/cgi/wiki?AbstractTestCases
> >>
> >> So I have an abstract class "T" with all methods test for "I" annotated as
JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
> >>
> >>
> >> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and
I want to collect it under a common test suite "TS".
> >>
> >> I have tried this solution:
> >> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances
to the test suite.
> >> But this solution don't work because "T1" need to extend TestCase and in
"T1" I'm using JUnit 4 annotations.
> >>
> >> Any idea how to solve the problem?
> >>
> >> Thanks
> >> Federico
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >
>

--- In junit@yahoogroups.com, "Fedy2" <fedy2@...> wrote:
>
>
>
> --- In junit@yahoogroups.com, Mike Forsberg <bigmike@> wrote:
> >
> > I wonder why you are extending TestCase if you are using annotations?
> > Extending the TestCase class is the old 3.x way of doing things.
>
>
> I needed it to put my test classes into a testsuite. The addTest method accept
only Test interface implementations.

To cite an earlier post: this is the old way of doing things. Annotate the
suite-to-be with @RunWith(Suite.class)
and @SuiteClasses(...)
The test classes then neither need to extend some class or any annotation other
than @Test for the methods initiating the tests.
You may even look into the new 4.8 featue : categories.

Cheers,
   Georg

Hi!

TestCase is just a compatibility feature from earlier versions of Junit. You
likely want to do the following:
place only the common things into the abstract class T (you can use annotation
there).
Place the test-specifics into T1, T2,... and introduce a Suite
comprising T1, T2,...

OR is there a reason why you cannot refactor T into  smaller parts?

As for applying tests to different classes implementing the same interface, look
at parametrized tests. I used this in JLinAlg. You may need, though, a factories
for A and B implementing a common interface F.

Ho this hleps,
   Georg


--- In junit@yahoogroups.com, "Fedy2" <fedy2@...> wrote:
>
> Hi all,
>
> I have this situation:
> A big interface "I" which is implemented by the "A" and "B" classes.
>
> I've solved the problem of wrote only one test for both implementations using
the method described here:
>
> http://c2.com/cgi/wiki?AbstractTestCases
>
> So I have an abstract class "T" with all methods test for "I" annotated as
JUnit 4 specify, then I instantiate "T" passing "A" or "B" instance.
>
>
> Now, I need to split the tests in "T" in different classes "T1,.., Tn" and I
want to collect it under a common test suite "TS".
>
> I have tried this solution:
> "TS" extends TestSuite and on the constructor add the "T1,..,Tn" instances to
the test suite.
> But this solution don't work because "T1" need to extend TestCase and in "T1"
I'm using JUnit 4 annotations.
>
> Any idea how to solve the problem?
>
> Thanks
> Federico
>

>> But group exclusion has other uses, such as "running all the tests except
>> the slow ones", "excluding the ui tests", "excluding the Linux tests",
>> etc...
>
> <snip>
>
>Got it. So we seem in agreement that excluded categories may be
>useful, but a "broken" category is not the best argument for them.

I also agree.  I almost exclusively use categories to exclude certain types of
tests, such as database tests, slow tests, integration tests, etc. from my main
test run.  In fact, for me, putting tests into a category is an exception rather
than a rule: in other words, I only mark tests that I would *not* want to
execute on each run of the test suite.  All other tests get run on every run,
each time.

Hope that helps,

Rocco

From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of David
Saff
Sent: Sunday, November 22, 2009 10:53 PM
To: junit@yahoogroups.com
Subject: Re: [junit] Re: Categories in JUnit 4.8



2009/11/22 CĂ©dric Beust â™” <cbeust@...<mailto:cbeust%40google.com>>:
> On Sun, Nov 22, 2009 at 7:36 PM, David Saff
<david@...<mailto:david%40saff.net>> wrote:
>
>>
>> > The problem with @Ignore is that 1) you need to specify it on all the
>> > methods you want to exclude and 2) it forces a recompilation.
>> >
>> > Being able to specify "-ignore broken" at runtime allows you to exclude
>> > dozens of methods in one single command.
>>
>> This story makes sense to me if you have many tests in the broken
>> group, and sometimes want to run all of them, and sometimes want to
>> run none of them. Is that your frequent experience? If so, I agree
>> that excludable categories would be the way to do it.
>>
>
> No, I never really run all the methods in the excluded groups, most of the
> time, their purpose is just to be excluded.  When I want to start fixing the
> broken tests, I look at all the tests in that group and I take them out of
> it one by one as I fix them.
>
> But group exclusion has other uses, such as "running all the tests except
> the slow ones", "excluding the ui tests", "excluding the Linux tests",
> etc...
>
> Admittedly, this is more on the integration/functional than on the unit test
> side, so you might consider these out of scope for JUnit.

Got it. So we seem in agreement that excluded categories may be
useful, but a "broken" category is not the best argument for them.

David Saff

>
>
>> In my frequent experience, I tend to never run all the tests in the
>> "broken" set: I enable them one by one, and fix them, when I can, so
>> @Ignore works fine for me.
>>
>
> That's also my experience for the Broken category.
>
> --
> ***CĂ©dric
> *
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



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

I think that is a great point. It may often be more practical to tag tests for
exclusion, based on execution time or external resource constraints than to tag
fast tests.

I found it easier to use assumptions to exclude such tests, because I can state
the assumption in a setup class that sets up the intensive resource and have the
unit test automatically excluded just for writing it, but I can definitely see
categories being a good exclusion mechanism.

--- In junit@yahoogroups.com, "Pigneri, Rocco" <rpigneri@...> wrote:
>
> >> But group exclusion has other uses, such as "running all the tests except
> >> the slow ones", "excluding the ui tests", "excluding the Linux tests",
> >> etc...
> >
> > <snip>
> >
> >Got it. So we seem in agreement that excluded categories may be
> >useful, but a "broken" category is not the best argument for them.
>
> I also agree.  I almost exclusively use categories to exclude certain types of
tests, such as database tests, slow tests, integration tests, etc. from my main
test run.  In fact, for me, putting tests into a category is an exception rather
than a rule: in other words, I only mark tests that I would *not* want to
execute on each run of the test suite.  All other tests get run on every run,
each time.
>
> Hope that helps,
>
> Rocco
>
> From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of David
Saff
> Sent: Sunday, November 22, 2009 10:53 PM
> To: junit@yahoogroups.com
> Subject: Re: [junit] Re: Categories in JUnit 4.8
>
>
>
> 2009/11/22 CĂ©dric Beust â™" <cbeust@...<mailto:cbeust%40google.com>>:
> > On Sun, Nov 22, 2009 at 7:36 PM, David Saff
<david@...<mailto:david%40saff.net>> wrote:
> >
> >>
> >> > The problem with @Ignore is that 1) you need to specify it on all the
> >> > methods you want to exclude and 2) it forces a recompilation.
> >> >
> >> > Being able to specify "-ignore broken" at runtime allows you to exclude
> >> > dozens of methods in one single command.
> >>
> >> This story makes sense to me if you have many tests in the broken
> >> group, and sometimes want to run all of them, and sometimes want to
> >> run none of them. Is that your frequent experience? If so, I agree
> >> that excludable categories would be the way to do it.
> >>
> >
> > No, I never really run all the methods in the excluded groups, most of the
> > time, their purpose is just to be excluded.  When I want to start fixing the
> > broken tests, I look at all the tests in that group and I take them out of
> > it one by one as I fix them.
> >
> > But group exclusion has other uses, such as "running all the tests except
> > the slow ones", "excluding the ui tests", "excluding the Linux tests",
> > etc...
> >
> > Admittedly, this is more on the integration/functional than on the unit test
> > side, so you might consider these out of scope for JUnit.
>
> Got it. So we seem in agreement that excluded categories may be
> useful, but a "broken" category is not the best argument for them.
>
> David Saff
>
> >
> >
> >> In my frequent experience, I tend to never run all the tests in the
> >> "broken" set: I enable them one by one, and fix them, when I can, so
> >> @Ignore works fine for me.
> >>
> >
> > That's also my experience for the Broken category.
> >
> > --
> > ***CĂ©dric
> > *
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>