Greg explains why he likes JUnit:

there are two things that make JUnit great:

1. what they left out and
2. the fact that it’s pretty much THE standard for writing unit tests

I certainly acknowledge point 2 since I provide a JUnit mode in
TestNG (read:  I emulate JUnit’s bugs
:-)).  But you can’t possibly be serious about point 1, Greg, can you? 
What is good about JUnit is what they left out?!?

Here is what happens
when a framework is not only simple but simplistic:  people start fixing
its deficiencies on their own and you end up with an explosion of customized
tools built on top of it.

Witness the following email, that was posted on the Groovy mailing-list just
yesterday where Guillaume Laforge explains what they have added to JUnit to make
testing easier:

Moreover, there are some other convenient assert* methods:

– assertArrayEquals(Object[] expected, Object[] value)
– assertLength(int length, char[] array)
– assertLength(int length, int[] array)
– assertLength(int length, Object[] array)
– assertContains(char expected, char[] array)
– assertContains(int expected, int[] array)
– assertToString(Object value, String expected)
…

(by the way, the Groovy dudes have added some pretty cool JUnit stuff to
their shell, you should check it out)

Greg adds:

I for one am glad not to have to deal with multiple frameworks.

That’s an interesting thought too.  I tend to favor the other approach,
though:  encourage people to be creative and come up with all sorts of
crazy ideas and frameworks, and let the market pick a winner.  I mean… 
are you really saying you wish there was Struts and only Struts?

Every new project you start on you’d be learning yet another testing
framework.

No, you are mixing up "concepts" and "implementations".  The concepts of
unit testing are fairly basic and well-known, and even though TestNG and JUnit
offer two radically different approaches to this problem, they implement the
same idea and I’m pretty sure that a developer familiar with one will have no
problem switching to the other.

At any rate, my goal was to get people to rethink unit testing and question
what they consider for granted, so at least, TestNG was successful in that. 
Finally, be sure to read

Mike’s recent blog entry, where he summarizes the main issues with unit
testing quite eloquently.

Robert (sorry, couldn’t figure out his name) wrote a
few
interesting criticisms about TestNG:

JUnit’s got huge traction in the Java community because of the tool support.

I disagree.  I think JUnit got traction because there was nothing else
when it came out.  It was simple, lightweight, easy to use, so everybody
adopted it.  Fair enough.  Then its limitations started showing and
since its development was pretty much stopped then, people started building
tools to work around its limitations.

And here is where I think the problem is with JUnit:  the JUnit tools
fix deficiciencies in its design.  For example, the ant task allows you to launch
the runner on a wildcard of classes or suites, which you can’t do with JUnit. 
A lot of the value added by these tools should have been retrofitted in JUnit by
now.  But they haven’t, because JUnit is basically a dead project by now.

If the only way you can easily launch tests remains from the command-line,
it’s not going to work very well.

I am not so sure about that either.  Running tests from your IDE is
definitely a plus (and I plan on writing an Eclipse plug-in once Eclipse
understands JSR 175 annotations), but I believe that most of unit testing happens in
automated builds.  A good testing framework needs to be extremely flexible
from the command line, that’s a requirement.  Which, as I said above and
in
previous
postings, JUnit fails to achieve in many ways.

Case in point: how can I easily launch, in TestNG, both my older JUnit tests
and the new-fangled ones?

It’s pretty easy to do, but you will need to run the launcher twice. 
This is just because I made the "JUnit compatibility flag" per-suite instead of
per-test.  It seems to make more sense this way, but this is pretty easy to
modify.

I hate the way the only log format for TestNG is a
HTML file.

I agree.  This was just a proof of concept to get you started. 
Right out of the box, TestNG gives you an easy-to-read HTML page that the most
novice user can read and understand.  But TestNG is fairly extensible and
easy to modify.  Since it’s such an early stage, I haven’t had the time to
polish that part yet, but there is an important part of TestNG that you might
have overlooked:  it gives you an API to inspect its running process.

For example, you can add listeners that will keep you informed when a test
starts, when it ends, if it succeeded, if it failed, why, etc…  As you
can see, adding your own logger and report generator is straightforward. 
In comparison, JUnit is a big black box.

There’s not a single Decorator in sight in TestNG.

Let’s take this offline, I’m not quite sure what you are asking for here.

Not to be nitpicky, but… I absolutely loathe the use of the ‘I’ to
mark an interface. Can’t stand it. Makes me shudder and have flashbacks to when
I used to write Microsoft
COM code in C.

Ah, well, sorry about that.  It’s a widely-used standard, though
(Microsoft, Eclipse and WebLogic Workshop use it, and they certainly know their
stuff…).  You’ll get used to it 🙂

At any rate, thanks for the feedback.  Contrary to what a lot of people
think, I didn’t write TestNG to kill JUnit but to make people think.  So
many toolkits and frameworks are considered for granted these days that nobody even
thinks of improving them any more (e.g JUnit, Velocity or XDoclet to name a
few).  If TestNG causes JUnit to be improved, I’m all for it!

That being said, I have had a few more ideas to improve TestNG recently,
which will show how powerful annotations can be compared to the "old way". 
Stay tuned, I’ll blog about this very soon.

Robert, feel free to email me so we
can continue the discussion!

The AOP panel at JavaOne was a big success.  Maybe it was because of the
provocative title ("AOP : The next big thing or giant leap backward"), which was
concocted by the mischievous Graham.  Maybe it was because James draws a
lot of attendance.  Or maybe, just maybe, it’s that more and more people
are getting extremely curious about AOP.

The panel was moderated by Simon Phipps and featured:

• Gregor Kiczales, as the "father of AOP".
• Graham Hamilton, as "the skeptic".
• Myself, as the "Conflicted AOP advocate"
• James Gosling, as… well, himself.

Somebody told me after the panel that not only was the main room full, but
the overflow room was standing room only, which probably adds up to an audience
of 2000-2500 people.

Simon opened the debate by asking a quick show of hands asking how many
people had already heard of AOP, and I estimate that 90% of the hands came up. 
When the question was refined to "Who has used AOP?", a great deal of hands went
down but quite a few remained up.

Gregor opened the debate by a ten-minute introduction on AOP, which is quite
a tour de force.  Using a simple application drawing shapes, Gregor
quickly showed how concerns get scattered into your code, what aspects and
pointcuts are and how they can help you write cleaner code.

Graham raised concerns about the loss of simplicity seen in the approach
offered by AOP.  He said that throughout the years, Sun has gone to great
lengths to keep the language simple, but with AOP, a simple Java line such as "a
= b * foo()" no longer means what you think it means.

When my turn came, I explained the reason for my internal conflict.  In
short, I see a lot of potential in AOP but I still perceive it as extremely
complicated and representing a steeper learning curve than most Java developers
are willing to climb.  I will expand on these ideas in a separate blog
entry.

Finally, James offered his ideas on AOP, starting by his very simple opening: 
"I like AOP a lot".  His concerns are a bit different from Graham’s,
though:  James is more afraid of the paradigm shift represented by AOP
while we are just barely getting used to OOP.

The panel went by really quick and unfortunately, I don’t remember most of
the questions we were asked (except one likening AOP to Lisp, which offered many
features similar to AOP, especially Lisp dialects that offered a Meta-Object
Protocol).

I have the feeling we achieved something important last week.  There was
no bickering about technical details on AOP frameworks nor any personal agendas
pushed in outrageous ways.  It was a simple exchange of views from people
genuinely interested in helping developers write better code,

If anything, we showed the audience that AOP was taken very seriously and
considered in very pragmatic terms by a lot of people these days.  Whether
you think you will be using AOP in your work or not, I strongly recommend you
take some time to study its major concepts.  I guarantee that even if you
day job is to write C code, you will end up reusing these concepts in your own
way and your code will greatly benefit from it.