Taking JUnit Out of the Box
Subject:   Toto, I don't think we're in Kansas anymore
Date:   2005-07-26 06:42:18
From:   jt2190

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?

1 to 1 of 1
1 to 1 of 1