Article:
  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?

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Amir Shevat photo Toto, I don't think we're in Kansas anymore
    2005-07-26 08:02:46  Amir Shevat | O'Reilly Blogger [View]

    You raised a few point, I will try to address them all:

    1) JUnit is only good for the "gear" and not for the "engine"- Confounding JUnit to the "gear" is somewhat limiting and does not do justice to JUnit, with a little out-of-the-box thinking and the use of advance JUnit features like parallel testing one can create test suites that test functionality and integration as well as units.

    2) call/callback are two methods - I am not sure my point was understood, let's say I want to invoke an asynchronous method (like opening a non blocking socket in NIO), I can not tell if the expected result had accrued without a callback mechanism. I hope this example make it clearer.

    3) JUnit is white-box/black-box - well, if you take a unit and you invoke method in it, the unit itself is a small black box, you are not aware of the internals of the process. JUnit tests functionality in a Boolean manner, if the functionality is correct but the process is faulty JUnit will not be able to detect that. I did not understand you comment about "finding memory-leaks with JUnit will be difficult, since your tests don't run in their native environment (the application), but in the test harness", can't a unit leak memory?

    4) "How is it difficult to write unit tests in Java" - nothing is difficult if you know what you are doing, we could all write our tests in binary code. My point was that some people think that writing tests using scripts is easier and nicer.

    5) "Toto, I don't think we're in Kansas anymore" -I find the title of your comment somewhat unclear, I hope you meant "I really enjoyed this article..." :)

    Amir Shevat