Re: Title: JUnit 4.9b2 (beta-)released

[everyone, be sure to reply-all to be sure the list is included (the
sourceforge lists seem to have less reliable Reply-To fields.)]



On Thu, Feb 3, 2011 at 4:32 PM, dgageot <[email protected]> wrote:
> Hi, everyone. Thank you for the good work.
>
> I was wondering, what made you choose TestRule to be an abstract class an=
d not an interface? This is so much of a pain.

In your position, I'd also be frustrated.

> The class being empty, I don't get it.

The idea was to guide people away from an improper usage of Rules.
For example, calling Timeout.apply in the middle of a test method is
so likely to be the wrong thing to do, that we wanted to make it
difficult.  If there were some way for a rule to expose one interface
to the framework, and another to test writers, that would be ideal.
This seemed like the next-best solution.

> One of my custom Rules needs to extend a class already.

Can you go into more details about this case, and how hard it would be
to adapt your code to use TestRule?

> If I leave it implementing the deprecated MethodRule, everything is ok as=
 long as I don't add another rule to the test.
> If a rule based on TestRule is used, any rule based on MethodRule seems t=
o be silently ignored.

This isn't what should be happening.  The ordering of multiple rules
is undefined.  What this means is that if you have a Rule (whether
TestRule or MethodRule) that sometimes or always blocks or interrupts
the call to base.evaluate(), then it may prevent other rules from
starting or completing.

There's been recent discussion on a way to be explicit about the
ordering of rule application.  If that would be helpful here, let me
know.

So, I now have 1 user (kcooney) on record for preferring the abstract
superclass (because it prevents confusion and improper usage), and one
(dgageot) on record preferring the interface (because it frees up the
superclass slot).  If anyone else has opinions, please chime in by
this time Monday, so we can make a decision and lock it in.  Thanks,

   David Saff

>
> David.
> @dgageot
>
>
> --- In [email protected], David Saff <david@...> wrote:
>>
>> Hello, everyone. =A0We're happy to announce the release of JUnit 4.9b2.
>> This release's theme is Test-class and suite level Rules.
>> More information linked from
>> http://saffgreenbar.blogspot.com/2011/01/junit-49b2-beta-released.html,
>> and release notes below.
>> Share and enjoy, and please try it out and give us feedback. =A0Thanks,
>>
>> Your friendly neighborhood JUnit maintainers
>>
>>
>> ## Summary of Changes in version 4.9 [unreleased!] ##
>>
>> Release theme: Test-class and suite level Rules.
>>
>> ### ClassRule ###
>>
>> The `ClassRule` annotation extends the idea of method-level Rules,
>> adding static fields that can affect the operation of a whole class. =A0=
Any
>> subclass of `ParentRunner`, including the standard `BlockJUnit4ClassRunn=
er`
>> and `Suite` classes, will support `ClassRule`s.
>>
>> For example, here is a test suite that connects to a server once before
>> all the test classes run, and disconnects after they are finished:
>>
>> =A0 =A0 =A0 @RunWith(Suite.class)
>> =A0 =A0 =A0 @SuiteClasses({A.class, B.class, C.class})
>> =A0 =A0 =A0 public class UsesExternalResource {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 public static Server myServer=3D new Server(=
);
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 @Rule
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 public static ExternalResource resource=3D n=
ew ExternalResource() {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 @Override
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 protected void before() thro=
ws Throwable {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 myServer.con=
nect();
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 @Override
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 protected void after() {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 myServer.dis=
connect();
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>> =A0 =A0 =A0 }
>>
>> ### TestRule ###
>>
>> In JUnit 4.9, fields that can be annotated with either `@Rule` or `@Clas=
sRule`
>> should be of type `TestRule`. =A0The old `MethodRule` type, which only m=
ade sense
>> for method-level rules, will still work, but is deprecated.
>>
>> Most built-in Rules have been moved to the new type already, in a way th=
at
>> should be transparent to most users. =A0`TestWatchman` has been deprecat=
ed,
>> and replaced by `TestWatcher`, which has the same functionality, but imp=
lements
>> the new type.
>>
>> `TestRule` is an abstract base class, and its abstract `apply` method is
>> protected. =A0In order to apply `TestRule`s to a `Statement`, use the `R=
unRules`
>> class in `org.junit.rules` (thanks to `@kcooney`)
>>
>> ### LICENSE checked in ###
>>
>> The Common Public License that JUnit is released under is now included
>> in the source repository.
>>
>> ### Bug fixes ###
>>
>> - github#98: assumeTrue() does not work with expected exceptions
>> - github#74: Categories + Parameterized
>>
>> =A0 In JUnit 4.8.2, the Categories runner would fail to run correctly
>> =A0 if any contained test class had a custom Runner with a structure
>> =A0 significantly different from the built-in Runner. =A0With this fix,
>> =A0 such classes can be assigned one or more categories at the class lev=
el,
>> =A0 and will be run correctly. =A0Trying to assign categories to methods=
 within
>> =A0 such a class will flag an error.
>>
>> - github#163: Bad comparison failure message when using
>> assertEquals(String, String)
>>
>> =A0 Thanks to `@kcooney`
>>
>> ### Minor changes ###
>>
>> - Backed out unused folder "experimental-use-of-antunit", replaced by
>> =A0 bash-based script at build_tests.sh
>>
>> - Made MultipleFailureException public, to assist extension writers.
>> =A0 Thanks to `@kcooney`
>>
>
>
>

---------------------------------------------------------------------------=
---
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? =

http://p.sf.net/sfu/oracle-sfdevnlfb