[re-adding list] ... Note that the release frequency and pace of enhancements are only loosely connected. ... Would this help in all of the cases above? I can
Message 1 of 4
, Mar 22 7:31 AM
On Mon, Mar 21, 2011 at 9:34 AM, Rogerio <rliesenfeld@...> wrote:
> Great news!
> I would really be happy to see more frequent JUnit releases, though. I believe there are big and important enhancements to be made.
Note that the release frequency and pace of enhancements are only
> Specifically, I would like to see JUnit provide better support for other testing tools, such as mocking frameworks, BDD tools, tools for integration/functional testing, etc. There are literally dozens of other tools which today provide some form of JUnit integration, usually in the form of base test classes or custom runners for use in @RunWith annotations. Some examples include jMock, Mockito, JMockit (my own tool), PowerMock, JBehave, Spock, Spring Test.
> Ideally, users should not be forced to add specific code in each test class just so another tool can integrate itself to the JUnit test execution process. For example, a user shouldn't have to add a specific rule to each test class, or to annotate potentially hundreds of test classes with @RunWith. Instead, better integration hooks should be provided in the form of test run listeners, combined with a mechanism to install such listeners transparently at startup (see issue 80).
Would this help in all of the cases above? I can see how it might
help for JMockit, which uses a static API accessed through
constructors. However, other frameworks, like jMock, use a local
container like a Mockery or Context to protect tests in different
threads from each other, and so it makes sense to use something like
Rules to provide both the test hook and access to the container, so a
generic listener framework helps little there.
I just wanted to be sure how broad you believe the applicability of issue 80 is.
> Other needs that certain tools may have include the ability to have custom parameters in test methods (JMockit already does this, by modifying the JUnit implementation at runtime - not a clean solution, of course), and to obtain access to test class instances so that field injection can occur (this could be added into Description).
> Just like TestNG, JUnit is *fundamental software*. Other testing tools will only be able to provide the best user experience if integration can be made seamless.
I've long been a fan of the principle (imported from Perl) that "All's
fair if you predeclare". I think that if using an extension requires
more than one line per extended class, that's a place the framework
can improve. However, if users will give us that one line per class,
whether as a Rule, @RunWith, or base class (in my current order of
preference), it has a big pay-off for both the framework and the user.
For example, it allows IDEs and continuous integration frameworks to
run individual classes or methods or subsets without having to keep an
eye on a global configuration. It also gives people who land in the
source code an easily-followable hint about what's going on.
I'd be happy to see an example where these goals (subset running and
local code understanding) can be met while not requiring even one line
of per-class predeclaration.
> --- In email@example.com, David Saff <david@...> wrote:
>> Over the last week or so, I've triaged almost 200 JUnit issues that
>> have accumulated over the last year, closing about 80 truly invalid
>> issues that were fixed, duplicates, or no longer made sense. I tagged
>> the rest with:
>> - regression bugs (9): there was an implementation of the feature that
>> worked prior to the 4.9 beta (although potentially earlier than
>> - nonregression bugs (15): it is likely the feature has always failed
>> in the documented way.
>> - features (~95): additions to the (implicit) spec, with
>> implementations to provide the additions.
>> Thanks to everyone who has been submitting problems, proposals, and
>> patches. I'm sorry that some of you have been waiting so long for a
>> The next part of the development plan, in order:
>> - Fix the regression bugs
>> - Release a 4.9 beta 3
>> - Hopefully 4.9b3 can become the final release. (I am not planning
>> any nonregression bug fixes or new features to get into the 4.9
>> release. We need to steer this ship back toward frequent releases.)
>> - Create a github project for junit.contrib.
>> - Go through the backlog of pull requests, to see which can be
>> accepted as is, and which either need changes, or should be redirected
>> into junit.contrib.
>> - Work through non-regression bugs for further releases in the 4.9.x series
>> - Choose a number of highly-rated feature requests to be the scope for
>> 4.10, and begin (patch acceptance / implementation)
>> I'm excited to see this project keep moving forward,
>> David Saff
Your message has been successfully submitted and would be delivered to recipients shortly.