||Taking JUnit Out of the Box|
|Subject:||Toto, I don't think we're in Kansas anymore|
A unit test is a specific kind of test: A single piece is taken out of it's operational environment, placed in a test harness, and tested. For example, you might take a gear out of an engine and test it to make sure it can endure operation inside of the engine over time.
I think you've confounded unit testing with integration or functional testing, and of course JUnit isn't going to provide a lot of out-of-the-box help with this.
For example, you state:
JUnit's weaknesses are also well known. It supports only synchronous testing and offers no support for call backs and other asynchronous utilities.
A call/callback mechinism is two units (two methods). You also state:
JUnit is a black-box testing framework, so testing problems that do not directly affect functionality (such as memory leaks) is very hard.
JUnit is white-box (or clear box) testing. You write code. You write tests for the code you wrote. There is nothing about the code being tested that is hidden.
Yes, finding memory-leaks with JUnit will be difficult, since your tests don't run in thier native environment (the application), but in the test harness.
Additionally, it does not provide an easy-to-use scripting language, so you must know Java to use JUnit.
I agree that a scripting language is nice when writing unit tests, however, if you're writing code in Java, how is it difficult to write unit tests in Java?