From: David S. <da...@sa...> - 2009-10-27 12:57:31
|
If a feature is rarely used, I prefer forcing some verbosity on code writers in order to prevent surprises on the part of the readers. If a feature is often used enough that it becomes part of the "vernacular" of the library, then both writers and readers win with brevity. Of course, only by releasing something can we be sure how often it will be used. I'd like to go with the more verbose version. Would you like to incorporate that into your patch, or wait until Kent or I have time to do it? Thanks, David Saff On Mon, Oct 26, 2009 at 7:55 PM, Alistair Israel <ai...@gm...> wrote: > 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 > |