It’s been a few weeks since I announced another killer app, hasn’t it?
I have complained about JUnit many times, both in
terms
of
design and
implementation.
I think my complaints are justified, but if there is something I don’t like,
it’s people who complain but don’t do anything to solve the problem they are
complaining about.
Therefore, without further ado, I give you…
TestNG, the JUnit killer.
For quite a while, I have seen very little reason to write a replacement to
JUnit since I didn’t think the added value would be enough to convince the vast
number of JUnit users to switch. After reading up about NUnit, it occurred
to me that using JSR 175 annotations for testing was an interesting evolution,
but still not quite the quantum leap I expected (besides, in its effort to
mimick JUnit, NUnit repeats a lot of its flaws).
So I went back to the drawing board, in search of one last killer argument to
justify taking on this endeavor, and I came up with another ultimate complaint
that, strangely, I hadn’t voiced about JUnit: the test Suite.
I have always been confused by JUnit’s Test Suites. Where should the
method belong? In the test class? Separately? Should it be
static? And if I want to change the tests run, why do I need to rebuild my
code?
With these changes in mind, I came up with the design principles that are the
foundation of TestNG. To quote the documentation:
TestNG is a testing framework inspired from JUnit and NUnit but
introducing some new functionalities that make it more powerful and easier
to use, such as:
- JSR 175 Annotations.
- Flexible test configuration.
- Default JDK functions for runtime and logging (no dependencies).
- Powerful execution model (no more TestSuite).
I think the combined use of JSR 175 annotations and Test Groups make TestNG a
very flexi… (augh, sorry Hani)… a very supple testing framework
that should compare decently with JUnit.
Check out the documentation, take it
for a run and let me know what you think.