JUnit Testing -- What makes it so useful over manual testing?
I understand the importance of testing and unit testing in general, but is JUnit used ubiquitously in the real world, and what are the advantages of using it over a "manual" test method? That is to say, why use a JUnit Test:
public class MyTest extends TestCase
{
public void testSomething()
{
assertTrue(someCondition);
assertTrue(manyOtherConditions);
}
}
versus some kind of lightweight custom-coded unit debugging tool
public class MyTest
{
public static void testSomething()
{
MyDebugUtility.println(someCondition);
MyDebugUtility.println(expectedCondition);
}
}
and checking the return 开发者_JAVA技巧values yourself? Either way you'll have to make a comparison between conditions, and with Unit Tests, it seems VERY easy to make a slip in your test code (as I've done) and wonder why your class isn't working when your real error was accidentally typing assertTrue rather than assertFalse.
Even if you wanted the easy boolean functionality, what makes JUnit superior to
public class MyTest
{
public static void testSomething()
{
if(condition1)
MyDebugUtility.println("Passed condition1");
else
MyDebugUtility.doError(); //handle however you want
}
}
Are there more powerful features of JUnit that I'm missing? Most of the unit tests I've written just seemed like cumbersome versions of some simple printing and boolean checking.
To answer the first question - yes, in practice, just about any serious software company will use some form of automated unit testing. Just a few of the many reasons to use an off-the-shelf unit testing framework:
Do you really want to hand-check 1000 print statements? Wouldn't you rather have the computer do it for you and just tell you "yep, everything's all right" so you can get back to coding?
They can be run by a script as part of a build, or on every commit. Used in this way, nobody has to remember to run them (and being human, we'll often forget).
The test framework has already been written and debugged. If you're worried about introducing bugs in the course of building your tests, I'd worry far more about making a mistake in the construction of an entire testing framework from scratch than about making a simple logical error in a few tests.
As seand points out, xUnit-type frameworks are so common that they're usually integrated into other types of tools - IDEs will run them, and continuous integration tools like Hudson can parse their logs and track their success/failure rate over time, or notify you via email when they fail. This is all functionality you'd have to build yourself - and although you may not need/want it now, if you ever do in the future, it'll be available.
Testing framework like JUnit, NUnit, etc. give you a lot of functionality for free that you don't have to implement yourself. For example, JUnit will automatically invoke test methods for you, setUp(), tearDown(), etc. It also has lots of helper assertion methods.
Another plus is JUnit is typically integrated in IDE's.
None of this is rocket science and you could implement this yourself. I've had to roll my own JUnit-like functionality before. But unless you have a special need why bother?
In short, it's a standardised approach to unit testing. His increases developer familiarity and improves integration with tooling (build tools, CI, code analysis etc).
JUnit can be integrated into continuos integration process with practically no effort so that if somebody broke the build all the team knows about this in a matter of minutes. This feature alone is worth using it.
Of course there are other useful features noted in other answer. JUnit is a wheel you really don't want to reinvent.
If you have something against JUnit try TestNG -- it may work for you better.
精彩评论