junit-devel — junit developers

Re: [Junit-devel] ClassRules

[Alistair I. <ai...@gm...>]

On Mon, Oct 26, 2009 at 9:51 PM, David Saff <da...@sa...> wrote:

> Note that we can get the "one object" behavior with the "two annotations" API:
>
> @ClassRule
> public static RemoteTestWatchman watchman = new RemoteTestWatchman();
>
> @Rule public RemoteTestWatchman methodWatchman = watchman;

Well, yeah I suppose that would work. Or you could simply annotate the
same field twice.

I guess ultimately it's a design decision. Personally, I like having
fewer annotations and letting the framework figure out my intent,
following published 'conventions', if need be. I can see others,
though, favoring explicit declarations of method-level rules vs.
class-level rules.

Since JUnit rules have only been out, oh, a couple of months(?) it
remains to be seen how others might use them and prefer to handle
class rules.

I've given my opinions for the record. I don't see anything wrong with
going either way and "failing fast"—after all, seeing the history of
JUnit you guys haven't been loathe to introduce something then
deprecate it soon enough afterward if something else made better
sense.

- alistair
-- 
http://alistairisrael.wordpress.com

Re: [Junit-devel] ClassRules

[David S. <da...@sa...>]

Alistair,

[I need to try to remember "reply all" and CC junit-devel so that
everyone stays involved; I keep forgetting]

On Sat, Oct 24, 2009 at 10:02 PM, Alistair Israel <ai...@gm...> wrote:
> On Fri, Oct 23, 2009 at 9:25 PM, David Saff <da...@sa...> wrote:
>
>> I think class-level rules make a lot of sense.  Do you think re-using
>> the @Rule annotation is better than a new @ClassRule annotation?
>
> Hi, again, David.
>
> Finally remembered another reason (in fact, my primary reason) for
> reusing @Rule.
>
> While in some cases, separating a ClassRule from a MethodRule makes
> sense (and allows for mixing and matching), in other cases that simply
> breaks encapsulation.
>
> The basic case is an expensive factory object or setup code that's
> used to provide a new instance of a resource to each @Test method. The
> ClassRule performs "around Class" setup & teardown, but the MethodRule
> would use the first to get new instance of the resource (which it uses
> for "around @Test" behavior).
>
> Consider a remote Web service that's used to report test results and
> timings to. (I know, it sounds contrived, but I don't want to keep
> harping about my own embedded DB + JPA + dependency injection use
> case.)
>
> The setup of the Web service is expensive, and ideally we'd want to
> set it up once before all tests, and cleanup after everything's done.
> Meanwhile, around each test we want to report start then
> success/failure.
>
> We could separate the two using:
>
>    @ClassRule
>    public static TestReportingWebService service = new
> TestReportingWebService();
>
>    @Rule
>    public RemoteTestWatchman watchman = new RemoteTestWatchman(service);
>
> Or, in my mind it'd be nicer to be able to go:
>
>    @Rule
>    public static RemoteTestWatchman watchman = new RemoteTestWatchman();

Note that we can get the "one object" behavior with the "two annotations" API:

@ClassRule
public static RemoteTestWatchman watchman = new RemoteTestWatchman();

@Rule public RemoteTestWatchman methodWatchman = watchman;

Is this better?

   David

Re: [Junit-devel] Junit Report

[David S. <da...@sa...>]

[Please reply to all to keep the mailing list in the thread]

Have you asked on the ant lists?  We don't have much to do with junitreport.

   David Saff

On Fri, Oct 23, 2009 at 11:10 AM, Tavo <gt...@vt...> wrote:
> This is:
>
> ******************************************************************
>
>         <junitreport todir="${reports.xml.dir}">
>             <fileset dir="${reports.xml.dir}">
>                 <include name="TEST-*.xml" />
>             </fileset>
>             <report format="frames" todir="${reports.html.dir}" />
>         </junitreport>
>
> ******************************************************************
>
> David Saff escribió:
>
> Have you looked at the junitreport ant task?
>
> On Fri, Oct 23, 2009 at 10:16 AM, Tavo <gt...@vt...> wrote:
>
>
> Hi
>       The test are running with ANT 1.7.1.
> This is the task
>
> ******************************************************************
> <junit fork="yes" failureProperty="test.failed"  printsummary="on"
> haltonfailure="no">
>             <!--
>         Specify the name of the coverage data file to use.
>         The value specified below is the default.
>             -->
>             <sysproperty key="net.sourceforge.cobertura.datafile"
>                          file="cobertura.ser" />
>             <!--
>                 Note the classpath order: instrumented classes are before
> the
>         original (uninstrumented) classes.  This is important.
>             -->
>             <classpath location="${instrumented.dir}" />
>             <classpath location="${classes.dir}" />
>             <classpath location="${testclasses.dir}" />
>             <classpath location="${testsrc.dir}" />
>             <classpath location="${testlib.dir}" />
>             <classpath path="${javac.test.classpath}" />
>
>             <!--
>                 The instrumented classes reference classes used by the
>         Cobertura runtime, so Cobertura and its dependencies
>                 must be on your classpath.
>             -->
>             <classpath refid="cobertura.classpath" />
>
>             <!--
>                 Generete the XML report for merging with CruiseControl log.
>             -->
>             <formatter type="xml" />
>             <batchtest todir="${reports.xml.dir}">
>                 <fileset dir="${testsrc.dir}">
>                     <include name="**/*TestSuite.java" />
>                 </fileset>
>             </batchtest>
>         </junit>
>
> ******************************************************************
> David Saff escribió:
>
> Tavo,
>
> How are you running the tests?
>
>    David Saff
>
> On Thu, Sep 24, 2009 at 4:36 PM, Tavo <gt...@vt...> wrote:
>
>
> Hi
>
>       After executing test based on TestSuites, the report detail shows
> only the name of the method executed, but not the class (*Test.java) it
> belongs. This make it very difficult to know exactly which test is
> failing, specially in classes like commands, where the only method is
> execute().
>
>       We need to customize the reports generated by junit, so it can
> show the actual test class, instead (or besides) the testsuite class.
>
>    Any advice will be much appreciated.
>
> Thanks,
> Tavo.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4536 (20091023) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4536 (20091023) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4536 (20091023) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4536 (20091023) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

[Junit-devel] AUTO: Fran Hughes is out of the office (returning 28/10/2009)

[Fran H. <fra...@ie...>]

I am out of the office until 28/10/2009.

I will have no access to email/voice mail during this time.
If your email is regarding an existing PMR, please contact
the IBM ECM Support via contact numbers as listed in
http://www.ibm.com/planetwide.
Otherwise I will respond to your message when I return.
If you have an urgent question relating to an issue please contact
the FRC via the hotline and request to speak directly to
my Technical Manager Pick One of the following:

Hannu Lindroos (hli...@ie...).
Douglas Good (dou...@ie...).
Damien Sinardet (Dam...@ie...)

With kind regards,

Fran Hughes


Note: This is an automated response to your message  "Junit-devel Digest,
Vol 25, Issue 1" sent on 23/10/09 15:08:53.

This is the only notification you will receive while this person is away.

Re: [Junit-devel] Junit Report

[David S. <da...@sa...>]

Have you looked at the junitreport ant task?

On Fri, Oct 23, 2009 at 10:16 AM, Tavo <gt...@vt...> wrote:
> Hi
>       The test are running with ANT 1.7.1.
> This is the task
>
> ******************************************************************
> <junit fork="yes" failureProperty="test.failed"  printsummary="on"
> haltonfailure="no">
>             <!--
>         Specify the name of the coverage data file to use.
>         The value specified below is the default.
>             -->
>             <sysproperty key="net.sourceforge.cobertura.datafile"
>                          file="cobertura.ser" />
>             <!--
>                 Note the classpath order: instrumented classes are before
> the
>         original (uninstrumented) classes.  This is important.
>             -->
>             <classpath location="${instrumented.dir}" />
>             <classpath location="${classes.dir}" />
>             <classpath location="${testclasses.dir}" />
>             <classpath location="${testsrc.dir}" />
>             <classpath location="${testlib.dir}" />
>             <classpath path="${javac.test.classpath}" />
>
>             <!--
>                 The instrumented classes reference classes used by the
>         Cobertura runtime, so Cobertura and its dependencies
>                 must be on your classpath.
>             -->
>             <classpath refid="cobertura.classpath" />
>
>             <!--
>                 Generete the XML report for merging with CruiseControl log.
>             -->
>             <formatter type="xml" />
>             <batchtest todir="${reports.xml.dir}">
>                 <fileset dir="${testsrc.dir}">
>                     <include name="**/*TestSuite.java" />
>                 </fileset>
>             </batchtest>
>         </junit>
>
> ******************************************************************
> David Saff escribió:
>
> Tavo,
>
> How are you running the tests?
>
>    David Saff
>
> On Thu, Sep 24, 2009 at 4:36 PM, Tavo <gt...@vt...> wrote:
>
>
> Hi
>
>       After executing test based on TestSuites, the report detail shows
> only the name of the method executed, but not the class (*Test.java) it
> belongs. This make it very difficult to know exactly which test is
> failing, specially in classes like commands, where the only method is
> execute().
>
>       We need to customize the reports generated by junit, so it can
> show the actual test class, instead (or besides) the testsuite class.
>
>    Any advice will be much appreciated.
>
> Thanks,
> Tavo.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4536 (20091023) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
>
>
>
> __________ Information from ESET Smart Security, version of virus signature
> database 4536 (20091023) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

Re: [Junit-devel] ClassRules

[Alistair I. <ai...@gm...>]

On Fri, Oct 23, 2009 at 9:25 PM, David Saff <da...@sa...> wrote:

> I think class-level rules make a lot of sense.  Do you think re-using
> the @Rule annotation is better than a new @ClassRule annotation?

Hi, David. Thanks for the vote.

In my branch, I didn't make a new @ClassRule annotation—just a new
ClassRule interface that's analogous to MethodRule.

ClassRule defines one method:

  Statement apply(Statement base, TestClass testClass);

The same @Rule annotation is use to specify a static class rule:

  @Rule
  public static DerbyResource derbyResource = new DerbyResource();

The only thing I haven't done is let a static @Rule be _both_ a
ClassRule _and_ a MethodRule—yet. I don't think it'll take much more
to get there, though.

- alistair
-- 
http://alistairisrael.wordpress.com

Re: [Junit-devel] Which list of bug/feature requests should I pick from?

[David S. <da...@sa...>]

Mike,

If you haven't noticed yet, we're prioritizing github, and when we get
to it, will be shutting down the sourceforge issues.

   David

On Thu, Sep 17, 2009 at 5:53 PM, Mike Forsberg <bi...@io...> wrote:
> I'll be freely available to work on JUnit issues soon and I'd like to
> start contributing to the project again.
>
> I noticed two lists of bug/feature requests... those on source forge
> and those on github.  Which should I be reading and submitting patches
> against.
>
> Big Mike
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

Re: [Junit-devel] ClassRules

[David S. <da...@sa...>]

Alistair,

I think class-level rules make a lot of sense.  Do you think re-using
the @Rule annotation is better than a new @ClassRule annotation?

   David

On Mon, Oct 19, 2009 at 6:05 AM, Alistair Israel <ai...@gm...> wrote:
> Hi, list.
>
> Hope I'm not overstepping by just barging in like this. Anyway, I'm
> one of those early adopters of JUnit 4.7's new @Rules.
>
> As I use them more and more I've also been seeing the usefulness of
> class-level rules more and more.
>
> A concrete use case of mine is initializing a JPA (Hibernate)
> persistence context backed by an embedded Derby database, then using
> DbUnit to load fixtures and populate the database.
>
> Using JUnit 4.7, I'm able to accomplish the above using a single
> MethodRule that does everything for every test method. The performance
> drawback should be obvious—we need to initialize Derby DB, set up
> Hibernate JPA, scan for annotated classes and create the tables to
> match the entities for _every test method_.
>
> I've taken the liberty of forking, branching, and committing some
> changes to JUnit that allow for class-level rules. It's up on GitHub,
> and the meat of the changes are here:
>  http://github.com/AlistairIsrael/junit/commit/79ef5a7e1d7fa144cc81c9414f4791aaea8b3d75
>
> The gist of it:
>  * Created the ClassRule interface that declares the apply(Statement,
> TestClass) method.
>  * Modified ParentRunner to scan for fields that are a) annotated
> with @Rule, b) static, and c) implement ClassRule.
>  * If any are found, then apply them in the order found, allowing
> them to append to the head of the Statement chain.
>  * Modified BlockJUnit4ClassRunner so validation treats ClassRules
> appropriately, and only apply MethodRules in methodBlock()
>
> I've also added a ClassRulesTest to AllTests to verify the above.
>
> Using a local-build, I successfully refactored my specific use-case
> and split the compound rule into a separate ClassRule (set up Derby
> and Hibernate) and a MethodRule (load DbUnit fixtures). Not only are
> the resulting tests more efficient, this strategy lets each Rule to be
> used independently, even allows for mixing and matching of different
> database, JPA or fixtures providers.
>
> I have a few more ideas on where this can go, but I'd like to get some
> feedback first if this is something that's welcome or if you guys have
> another direction you think we should take.
>
> Thanks,
> - alistair
> --
> http://alistairisrael.wordpress.com
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

[Junit-devel] Feature prioritization in JUnit

[David S. <da...@sa...>]

All,

For the last six weeks, I've been on paternity leave, which brought forward
progress on JUnit to an even slower crawl than usual.  In starting back up,
we recently received a helpful mail that challenged us to think harder about
our community responsiveness.  Even when we're at full productivity, there's
never been more active committers on JUnit than you could count on one hand,
and usually (including now), that hand could be missing most of its fingers.
We want the feature requests to continue, and even to accelerate, but we are
unlikely to implement feature requests at the speed that they are proposed.
Our practice with JUnit has always been to grow it slowly, adding features
only when they are obviously widely useful. Therefore, we should make clear
how your favorite feature request or patch can be among the few that get
implemented, integrated, and released.

>From here on, you can assume that we will be pulling work from the github
issues list at http://github.com/KentBeck/junit/issues.  We will generally
be pulling from the top of one of three stacks:

1) All bugs, sorted by votes:
   - http://github.com/KentBeck/junit/issues/labels/bug#sort=votes
2) All issues, sorted by votes:
  - http://github.com/KentBeck/junit/issues#sort=votes
3) All issues, sorted by priority (where priority is set by the development
team)
   - http://github.com/KentBeck/junit/issues#list

If your issue is at the top of one of those stacks, and you don't hear from
us for a couple weeks, please bug us to find out what's going on.

If your issue is _not_ at the top of one of those stacks, and you really
think it should be, it's time for some politicking.  You can convince the
development team that your issue is more important than our current top
priority, or you can convince the community to vote up your issue.

We appreciate issues that are solved by already-written patches, but we will
not necessarily prioritize a low-vote issue with a patch over a highly-voted
issue with no patch. Even if you submit a patch (with tests, naturally, and
please follow our coding conventions), we are unlikely to integrate it
unchanged. We say this because we never have incorporated a patch unchanged
in 12 years of development.

Thanks for your continued community support.  We love the programming, but
you help make it fun for us,

  David

[Junit-devel] ClassRules

[Alistair I. <ai...@gm...>]

Hi, list.

Hope I'm not overstepping by just barging in like this. Anyway, I'm
one of those early adopters of JUnit 4.7's new @Rules.

As I use them more and more I've also been seeing the usefulness of
class-level rules more and more.

A concrete use case of mine is initializing a JPA (Hibernate)
persistence context backed by an embedded Derby database, then using
DbUnit to load fixtures and populate the database.

Using JUnit 4.7, I'm able to accomplish the above using a single
MethodRule that does everything for every test method. The performance
drawback should be obvious—we need to initialize Derby DB, set up
Hibernate JPA, scan for annotated classes and create the tables to
match the entities for _every test method_.

I've taken the liberty of forking, branching, and committing some
changes to JUnit that allow for class-level rules. It's up on GitHub,
and the meat of the changes are here:
  http://github.com/AlistairIsrael/junit/commit/79ef5a7e1d7fa144cc81c9414f4791aaea8b3d75

The gist of it:
  * Created the ClassRule interface that declares the apply(Statement,
TestClass) method.
  * Modified ParentRunner to scan for fields that are a) annotated
with @Rule, b) static, and c) implement ClassRule.
  * If any are found, then apply them in the order found, allowing
them to append to the head of the Statement chain.
  * Modified BlockJUnit4ClassRunner so validation treats ClassRules
appropriately, and only apply MethodRules in methodBlock()

I've also added a ClassRulesTest to AllTests to verify the above.

Using a local-build, I successfully refactored my specific use-case
and split the compound rule into a separate ClassRule (set up Derby
and Hibernate) and a MethodRule (load DbUnit fixtures). Not only are
the resulting tests more efficient, this strategy lets each Rule to be
used independently, even allows for mixing and matching of different
database, JPA or fixtures providers.

I have a few more ideas on where this can go, but I'd like to get some
feedback first if this is something that's welcome or if you guys have
another direction you think we should take.

Thanks,
- alistair
-- 
http://alistairisrael.wordpress.com

[Junit-devel] Junit Report

[Tavo <gt...@vt...>]

Hi

       After executing test based on TestSuites, the report detail shows
only the name of the method executed, but not the class (*Test.java) it
belongs. This make it very difficult to know exactly which test is
failing, specially in classes like commands, where the only method is
execute().

       We need to customize the reports generated by junit, so it can
show the actual test class, instead (or besides) the testsuite class.

    Any advice will be much appreciated.

Thanks,
Tavo.

[Junit-devel] Which list of bug/feature requests should I pick from?

[Mike F. <bi...@io...>]

I'll be freely available to work on JUnit issues soon and I'd like to
start contributing to the project again.

I noticed two lists of bug/feature requests... those on source forge
and those on github.  Which should I be reading and submitting patches
against.

Big Mike

Re: [Junit-devel] [junit] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[David S. <da...@sa...>]

Stefan,

Thanks, the links should work now

On Thu, Jul 30, 2009 at 11:41 AM, Stefan
Bodewig<ste...@fr...> wrote:
> On 2009-07-28, David Saff <da...@sa...> wrote:
>
>> I think that we changed things back for the final release--let me know
>> if that's the case.  Thanks,
>
> Is the final release available by now?  The download link from junit.org
> sends me to a Sourceforge page that only has a snapshot I have already
> tried. [1]
>
> Anyway, I have modified xmlunit and with my modification it worked with
> Hamcrest 1.2 as well as 1.1 (otherwise I would have gotten a failure
> mail from our friend Apache Gump).
>
> I don't intend to switch back to the is(Class) usage since it will only
> bring us back into trouble if you ever try to use Hamcrest 1.2 again 8-)
>
> Thanks
>
>        Stefan
>
> [1] I later found the 4.7 release at Github, you may want to fix
>    the links at junit.org.
>

Re: [Junit-devel] [junit] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[Stefan B. <ste...@fr...>]

On 2009-07-28, David Saff <da...@sa...> wrote:

> I think that we changed things back for the final release--let me know
> if that's the case.  Thanks,

Is the final release available by now?  The download link from junit.org
sends me to a Sourceforge page that only has a snapshot I have already
tried. [1]

Anyway, I have modified xmlunit and with my modification it worked with
Hamcrest 1.2 as well as 1.1 (otherwise I would have gotten a failure
mail from our friend Apache Gump).

I don't intend to switch back to the is(Class) usage since it will only
bring us back into trouble if you ever try to use Hamcrest 1.2 again 8-)

Thanks

        Stefan

[1] I later found the 4.7 release at Github, you may want to fix
    the links at junit.org.

Re: [Junit-devel] [junit] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[David S. <da...@sa...>]

Stefan,

I think that we changed things back for the final release--let me know
if that's the case.  Thanks,

   David Saff

On Fri, Jun 5, 2009 at 7:13 AM, Stefan Bodewig<ste...@fr...> wrote:
> On 2009-06-03, David Saff <da...@sa...> wrote:
>
>> Stefan,
>
>> Logged here:
>
>> http://github.com/KentBeck/junit/issues#issue/9
>
>> I think I may have a solution, by following hamcrest's lead and
>> changing the signature of assertThat.  I'll release another snapshot
>> soon you can try.
>
> The snapshot still didn't do the trick and I think it is Hamcrest's
> Is.is(Class<T>) method.  The signature changed from
>
>                Matcher<Object> is(java.lang.Class<?>)
>
> to
>
>                <T> Matcher<? super T> is(Class<T>)
>
> I've changed XMLUnit's tests to use IsInstanceOf.instanceOf()
> explicitly instead of using the is() method and things compile and
> work correctly with both JUnit 4.6 and the 20090604 snapshot.
>
> Note that instanceOf also changed from
>
>                Matcher<Object> instanceOf(Class<?>)
>
> to
>
>                <T> Matcher<T> instanceOf(Class<?>)
>
> but it works (note it is still Class<?> in Hamcrest 1.2).
>
> BTW, if I compile the older test code using is() (XMLUnit svn trunk
> revision 342)
> <http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/>
> against 4.6 and run them with the latests JUnit snapshot things work
> just fine - it's just the code doesn't compile using the snapshot.
>
> Stefan
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel
>

Re: [Junit-devel] [junit] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[Stefan B. <ste...@fr...>]

On 2009-06-03, David Saff <da...@sa...> wrote:

> Stefan,

> Logged here:

> http://github.com/KentBeck/junit/issues#issue/9

> I think I may have a solution, by following hamcrest's lead and
> changing the signature of assertThat.  I'll release another snapshot
> soon you can try.

The snapshot still didn't do the trick and I think it is Hamcrest's
Is.is(Class<T>) method.  The signature changed from

                Matcher<Object> is(java.lang.Class<?>)

to

                <T> Matcher<? super T> is(Class<T>) 

I've changed XMLUnit's tests to use IsInstanceOf.instanceOf()
explicitly instead of using the is() method and things compile and
work correctly with both JUnit 4.6 and the 20090604 snapshot.

Note that instanceOf also changed from

                Matcher<Object> instanceOf(Class<?>)

to

                <T> Matcher<T> instanceOf(Class<?>)

but it works (note it is still Class<?> in Hamcrest 1.2).

BTW, if I compile the older test code using is() (XMLUnit svn trunk
revision 342)
<http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/>
against 4.6 and run them with the latests JUnit snapshot things work
just fine - it's just the code doesn't compile using the snapshot.

Stefan

Re: [Junit-devel] [junit] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[David S. <da...@sa...>]

Stefan,

Logged here:

http://github.com/KentBeck/junit/issues#issue/9

I think I may have a solution, by following hamcrest's lead and
changing the signature of assertThat.  I'll release another snapshot
soon you can try.

   David Saff

On Tue, Jun 2, 2009 at 5:44 AM, Stefan Bodewig
<ste...@fr...> wrote:
> On 2009-06-01, David Saff <da...@sa...> wrote:
>
>> If anyone can try compiling their pre-4.7 code which uses assertThat
>> against the new build, and can report results, it would be a great
>> help.
>
> Apache Gump uses JUnit's trunk for everything it builds, but most of
> the projects probably do't use assertThat at all.
>
> One project that started to fail after you managed to get JUnit's
> trunk compile on Java6 is xmlunit:
>
> http://vmgump.apache.org/gump/public/xmlunit/xmlunit/gump_work/build_xmlunit_xmlunit.html
>
> Since I'm the main developer of xmlunit right now, I was just about to
> ping you anyway.  So far I haven't found the time to look into the
> root cause or even try to find a way of fixing xmlunit's build.
>
> Stefan
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
>    http://groups.yahoo.com/group/junit/
>
> <*> Your email settings:
>    Individual Email | Traditional
>
> <*> To change settings online go to:
>    http://groups.yahoo.com/group/junit/join
>    (Yahoo! ID required)
>
> <*> To change settings via email:
>    mailto:jun...@ya...
>    mailto:jun...@ya...
>
> <*> To unsubscribe from this group, send an email to:
>    jun...@ya...
>
> <*> Your use of Yahoo! Groups is subject to:
>    http://docs.yahoo.com/info/terms/
>
>

Re: [Junit-devel] [junit] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[Stefan B. <ste...@fr...>]

On 2009-06-01, David Saff <da...@sa...> wrote:

> If anyone can try compiling their pre-4.7 code which uses assertThat
> against the new build, and can report results, it would be a great
> help.

Apache Gump uses JUnit's trunk for everything it builds, but most of
the projects probably do't use assertThat at all.

One project that started to fail after you managed to get JUnit's
trunk compile on Java6 is xmlunit:

http://vmgump.apache.org/gump/public/xmlunit/xmlunit/gump_work/build_xmlunit_xmlunit.html

Since I'm the main developer of xmlunit right now, I was just about to
ping you anyway.  So far I haven't found the time to look into the
root cause or even try to find a way of fixing xmlunit's build.

Stefan

[Junit-devel] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[David S. <da...@sa...>]

The latest snapshot build of 4.7 is junit-4.7-SNAPSHOT-20090601-1258.
This build upgrades the bundled version of Hamcrest up to 1.2, which
has effects on the Matchers used as targets of the assertThat()
statement.  If anyone can try compiling their pre-4.7 code which uses
assertThat against the new build, and can report results, it would be
a great help.  Share and enjoy,

   David Saff

More detailed notes:

- Hamcrest 1.2 is now incorporated.
  - The following methods from `JUnitMatchers` are deprecated, and
moved to `CoreMatchers`:
    - `JUnitMatchers.hasItem` is now `CoreMatchers.hasItem`
    - `JUnitMatchers.hasItems` is now `CoreMatchers.hasItems`
    - `JUnitMatchers.containsString` is now `CoreMatchers.containsString`

  - Matchers now have more informative mismatch descriptions.  For example:

      @SuppressWarnings("unchecked")
	  @Test public void stringIsAnInteger() {
	      assertThat("identifier", "actual", matches(is(Integer.class)));
	      // prints:
	      // Expected: is an instance of java.lang.Integer
	      //      but: \"actual\" is a java.lang.String
      }

  - Some matchers have slightly changed type signatures, especially
those created
    by `is()` and `equalTo`.  Everything should work, except see
`BothTest` for an
    example of how the `both().and()` and `either().or()` constructs may be
    affected.  To essentially disable type-checking for a matcher expression,
    use `JUnitMatchers.matches()` (see below)

  - `JUnitMatchers.isOneOf(...)` is sugar for the situation where you
want to specify
	a finite list of concrete objects that can match.  For example:

	  assertThat(3, isOneOf(3, 4));

  - `JUnitMatchers.matches()` disables type-checking of a matcher entirely.

	 Goofy example:
	
	    assertThat(3, matches(containsString("a")));
	
	 Real example:
	
	    assertThat(3, either(matches(is(String.class))).or(
		                     matches(is(Integer.class))));

[Junit-devel] JUnit 4.7 and Hamcrest 1.2

[David S. <da...@sa...>]

All,

I've spent an amazing chunk of this week getting Hamcrest 1.2 and
JUnit 4.7 to compile and play nicely together under both Eclipse
(easy) and javac 1.5 (hard).  In the end, I was thrilled to get
hasItem, hasItems, each, and containsString out of the JUnitMatchers
factory class, but I had to leave four convenience functions:

*** JUnitMatchers.both: Hamcrest 1.2 included both(), but changed its
type signature to allow this to compile:

CoreMatchers.both(is(3)).and(is(4))

This is a fairly rare thing to truly want to say.  This is more
common, and now does not compile:

CoreMatchers.both(containsString("first")).and(containsString("second"))

So, I left both() in JUnitMatchers with the original typing.  I'd be
interested in if Hamcrest would like to make the same choice.

*** JUnitMatchers.either: same as above, although with less certainty,
since this is more likely to be useful:

CoreMatchers.either(is(3)).or(is(4))

Thus...

*** JUnitMatchers.isOneOf(T...)

Instead of either(is(3)).or(is(4)), use

JUnitMatchers.isOneOf(3, 4);

*** JUnitMatchers.matches

Takes any matcher and returns a matcher of any other type:

	@SuppressWarnings("unchecked")
	public static <T> Matcher<T> matches(Matcher<?> matcher) {
		return (Matcher<T>)matcher;
	}

I expect to be saying "just wrap it in matches()" any number of times
on the JUnit mailing lists coming up.

   David Saff

[Junit-devel] Latest JUnit 4.7 snapshot, includes assertion on expected exception message text

[David S. <da...@sa...>]

All,

In the latest snapshot build of JUnit 4.7, we’ve re-implemented
expected exceptions using Interceptors.

Share and Enjoy, and let us know if the download experience is at all lacking.

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

	public static class HasExpectedException {
		@Interceptor
		public ExpectedException thrown= new ExpectedException();

		@Test
		public void throwsNothing() {

		}

		@Test
		public void throwsNullPointerException() {
			thrown.expect(NullPointerException.class);
			throw new NullPointerException();
		}

		@Test
		public void throwsNullPointerExceptionWithMessage() {
			thrown.expect(NullPointerException.class);
			thrown.expectMessage("happened?");
			throw new NullPointerException("What happened?");
		}
	}

Thanks,

   David Saff

[Junit-devel] Moving everything to github

[David S. <da...@sa...>]

All,

SourceForge has been a reliable hosting provider for JUnit's
management needs for many years.  However, several of the services for
which we used to look to SourceForge have moved to other providers:
junit.org is being hosted and maintained by 8thlight, the mailing list
is on yahoogroups, and, more recently, we've switched to github for
source control.

Today, we're going to, on an experimental basis, move issue tracking
and snapshot downloads to github as well.  GitHub allows issues to be
created in a couple fewer clicks, and new releases to be uploaded in
_many, many_ fewer clicks, than SourceForge, which should allow our
small team to be faster providing interim builds to play with, and
responding to issues.  We'll use the next couple of months to
transition.  Please immediately start tracking new bugs and feature
requests to:

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

And look for interim builds at:

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

We will probably continue to mirror stable releases through
SourceForge for at least the time being.

And please give feedback on the experience, either on this list, or on
the issue tracker itself.  Thanks,

   David Saff

[Junit-devel] New 4.7 snapshot release: get the name of the current test

[David S. <da...@sa...>]

All,

A new snapshot release of JUnit 4.7 is up:

https://sourceforge.net/project/showfiles.php?group_id=15278&package_id=226053&release_id=682045

The newest feature in this release is a golden oldie: access to the
name of the currently-running test method:

	@RunWith(Interceptors.class)
	public class NameInterceptorTest {
		@Interceptor public TestName name = new TestName();
		
		@Test public void testA() {
			assertEquals("testA", name.getMethodName());
		}
	}

Share and Enjoy,

   David Saff


P.S. The entire release notes:

## Summary of Changes in version 4.7 ##

### Interceptors ###

- Interceptors allow very flexible addition or redefinition of the behavior
  of each test method in a test class.  For example, this class will
  keep a log of each passing and failing test:

	@RunWith(Interceptors.class)
	public static class WatchmanTest {
		private static String watchedLog;

		@Interceptor
		public StatementInterceptor watchman= new TestWatchman() {
			@Override
			public void failed(Throwable e, FrameworkMethod method) {
				watchedLog+= method.getName() + " "
						+ e.getClass().getSimpleName() + "\n";
			}

			@Override
			public void succeeded(FrameworkMethod method) {
				watchedLog+= method.getName() + " " + "success!\n";
			}
		};

		@Test
		public void fails() {
			fail();
		}

		@Test
		public void succeeds() {
		}
	}

	For more on this feature, see http://www.threeriversinstitute.org/blog/?p=155

- The TestName Interceptor makes the current test name available
inside test methods:

	@RunWith(Interceptors.class)
	public class NameInterceptorTest {
		@Interceptor public TestName name = new TestName();
		
		@Test public void testA() {
			assertEquals("testA", name.getMethodName());
		}
		
		@Test public void testB() {
			assertEquals("testB", name.getMethodName());
		}
	}

- The Timeout Interceptor applies the same timeout to all test methods
in a class:

	@RunWith(Interceptors.class)
	public static class HasGlobalTimeout {
		public static String log;
		
		@Interceptor public StatementInterceptor globalTimeout = new Timeout(20);
		
		@Test public void testInfiniteLoop1() {
			log+= "ran1";
			for(;;) {}
		}
		
		@Test public void testInfiniteLoop2() {
			log+= "ran2";
			for(;;) {}
		}
	}

### Timeouts ###
- Tests that timeout now show the stack trace of the test thread.

### Docs ###
- Javadocs now link to online JDK javadocs (bug 2090230)
- Parameterized runner javadocs improved (bug 2186792)
- Fixed Javadoc code sample for AfterClass (2126279)
- Fixed Javadoc for assertArraysEqual(float[], float[])

### Bug fixes ###
- Fixed: BaseTestRunner.getTest() requires class to extend TestCase (1812200)
- Fixed: Suite does not allow for inheritance in annotations (2783118)
- Fixed: ParallelComputer skipped tests that took longer than 2 seconds

[Junit-devel] New 4.7 snapshot release: now with interceptors

[David S. <da...@sa...>]

All,

We've bundled the most recent changes in the 4.7 branch into a
snapshot release here:

https://sourceforge.net/project/showfiles.php?group_id=15278&package_id=226053&release_id=679069

We think the new Interceptor support is a simple but powerful way to
get more control on how your methods are run and reported, and are
eager for feedback

  David Saff

## Summary of Changes in version 4.7 ##

### Interceptors ###

- Interceptors allow very flexible addition or redefinition of the behavior
  of each test method in a test class.  For example, this class will
  keep a log of each passing and failing test:

	@RunWith(Interceptors.class)
	public static class WatchmanTest {
		private static String watchedLog;

		@Interceptor
		public StatementInterceptor watchman= new TestWatchman() {
			@Override
			public void failed(Throwable e, FrameworkMethod method) {
				watchedLog+= method.getName() + " "
						+ e.getClass().getSimpleName() + "\n";
			}

			@Override
			public void succeeded(FrameworkMethod method) {
				watchedLog+= method.getName() + " " + "success!\n";
			}
		};

		@Test
		public void fails() {
			fail();
		}

		@Test
		public void succeeds() {
		}
	}

	For more on this feature, see http://www.threeriversinstitute.org/blog/?p=155

### Timeouts ###
- Tests that timeout now show the stack trace of the test thread.

### Docs ###
- Javadocs now link to online JDK javadocs (bug 2090230)
- Parameterized runner javadocs improved (bug 2186792)
- Fixed Javadoc code sample for AfterClass (2126279)

### Bug fixes ###
- Fixed: BaseTestRunner.getTest() requires class to extend TestCase (1812200)
- Fixed: Suite does not allow for inheritance in annotations (2783118)

[Junit-devel] First JUnit 4.7 snapshot

[David S. <da...@sa...>]

All,

We've bundled the most recent changes in the 4.7 branch into a
snapshot release here:

https://sourceforge.net/project/showfiles.php?group_id=15278&package_id=226053&release_id=679069

We're especially interested if the new timeout stacktraces work well
with everyone's existing timeout tests.  Remember that snapshot
releases are at your own risk, however.

   David Saff

## Summary of Changes in version 4.7 ##

### Timeouts ###
- Tests that timeout now show the stack trace of the test thread.

### Docs ###
- Javadocs now link to online JDK javadocs (bug 2090230)
- Parameterized runner javadocs improved (bug 2186792)
- Fixed Javadoc code sample for AfterClass (2126279)

### Bug fixes ###
- Fixed: BaseTestRunner.getTest() requires class to extend TestCase (1812200)