When faced with unit testing, many teams end up producing some kind of testing framework. JUnit, available as open source, eliminates this onerous task by providing a ready-made framework for unit testing. JUnit, best used as an integral part of a development testing regime, provides a mechanism that developers can use to consistently write and execute tests. So, what are the JUnit best practices? |
This complaint can be addressed by doing some "out of the box" thinking. This article will describe how JUnit can perform complex test scenarios by introducing Pisces, an open source JUnit extension that lets you write test suites composed of several JUnit tests, each running on a remote machine serially or in parallel. The Pisces extension will allow you to compose and run complex scenarios while coordinating all of them in a single location. |
The Testing in isolation with mock objects chapter introduces and demontrates mock objects, shows how to use mock objects as a refactoring technique, how mock objects can verify API contracts on collaborating classes, and looks at how mock objects can be used an HTTP connection sample application. |
By now you should know why testing is valuable. If you don't, please see the first article in this five part series. The first article is a concept piece explaining why testing helps in an enterprise server-side software environment. Most software applications today are written in tiers: the presentation tier, the logic tier (where business logic is kept), and the data tier. The logic tier is the meat of the application and comprises all of the rules and actions of the application. The business logic usually resides in JAR files containing libraries of Java class files. People often think of testing as trying out a product. With a car, it's easy: start the ignition and drive. With desktop software, it's also easy: start up the application, then click around and type to test the functions that interest you. How do you test a JAR file filled with Java classes? |
When I first started to read JUnit in Action1, I was hoping that it wouldn't be a tutorial on the open source tool JUnit2. I am glad to say that it is much more. I think the book's name could really be "Testing in Practice". Sure, JUnit is covered in a lot of detail, but so are other tools such as: |
Let's face it, JUnit is the most widely used (unit-) testing tool in the Java world. There are other powerful test frameworks out there, such as TestNG (which is very comprehensive), but they've never enjoyed the broad acceptance JUnit has. With version 4, Kent Beck and Erich Gamma introduced the first significant API changes in the last few years. When the first release candidate was available back in 2005, you could hardly use it in a productive working environment due to the lack of tool support at that time. By now, most build tools and IDEs come with support for JUnit 4, so it's about time to give it a try. This article describes what's different compared to JUnit 3.8.x. |
JUnit is the glue that holds many open source projects together. But JUnit has problems performing multithreaded unit tests. This creates considerable difficulty for middleware developers in the open source J2EE market. This article introduces GroboUtils, a JUnit extension library designed to address this problem and enable multithreaded unit testing in JUnit. A basic understanding of JUnit and threads is recommended but not necessary for readers of this article. |
|
This week Matt Gerrans, Frank Sommers, and I released Artima SuiteRunner, a free open source testing toolkit for Java. You can use this tool with JUnit to run existing JUnit test suites, or standalone to create unit and conformance tests for Java APIs. JUnit, originally written by Erich Gamma and Kent Beck, is very popular among Java developers and especially the extreme programming (XP) community. Like most Java developers, when we needed to create tests we first turned to JUnit. But as we started using JUnit in our own projects, we encountered some limitations. We created a new tool, Artima SuiteRunner, that better addressed our testing needs. In this article, we explain why JUnit didn't fit the bill, and how Artima SuiteRunner was created. |
When I later ended up participating in the creation of what Frank Sommers, Matt Gerrans, and I eventually released as Artima SuiteRunner [3], I vowed that I would make the testing of private methods easier in SuiteRunner than it is in JUnit. But after investigating the various approaches to testing private methods, I decided not to do anything special in SuiteRunner to support testing private methods. So whether you are using JUnit or SuiteRunner, you have the same four basic approaches to testing private methods: |
To execute JUnit3Suites with ScalaTest's Runner, you must include JUnit3's jar file on the class path or runpath. This version of JUnit3Suite was tested with JUnit version 3.8.1. |
This article explains how to write Jython tests in an Eclipse/JUnit/continuous testing programming environment. It demonstrates setting up an environment with a simple class to test through a JUnit test case, and then adding a Jython test case that you can integrate seamlessly into the Eclipse JUnit view. |
Test Case Generation Benefits By extending JUnit with Jtest, you can automatically generate JUnit-compatible test cases that verify code construction, stability, and?if the class uses Eiffel Software's Design by Contract?functionality. This allows you to generate a foundational test suite you can extend with JUnit test classes. |
All of these contributing factors prevent tests from being automated. However, all is not lost. You can enable your tests to be executed without a lot of code refactoring or retooling. By building a simple JUnit test execution service that runs inside your application, you can support in container test execution via command-line, over HTTP, or even expose test execution as a Web service. Rather than running tests standalone using JUnit or IDE tools, you can execute them inside a deployed application. |
JUnit 4 is a completely different API from the versions that came before it and depends on new features of Java 5.0 (annotations, static importā¦). As you'll see, JUnit 4 is simpler, richer, and easier to use and introduces more flexible initialization and cleanup, timeouts, and parameterized test cases. |
New Tools for Your Bag of Tricks In an age when any professional Java developer has to know how to properly unit test the code he or she writes, JUnit, JUnit-Addons, and jfcUnit should be at the top of your bag of tricks. Use these tools to make writing your tests easier and more effective. Rarely will you need to dig deeper into your bag for less common tools. |
16. JUnit FAQ junit.sourceforge.netMost of the wisdom contained in this FAQ comes from the collective insights and hard-won experiences of the many good folks who participate on the JUnit mailing list and the JUnit community at large. |
One of the basics of a great development process is testing. Verification of work is an important part of any profession. A doctor might confirm a diagnosis with a blood test. Boeing tested airplane components during the development of the 777. Why should software development be any different? |
JUnit provides an effective and easy way to unit test client-side Java applications, but it has some limitations; therefore, testing in each application server container becomes a tedious process. The IBM Rational Application Developer platform features a Web-based Universal Test Client (UTC) that provides a seamless and integrated mechanism for unit testing Enterprise JavaBeans (EJBs). However, the Rational Application Developer UTC is an interactive unit-testing mechanism, thus it falls short when it comes to automating unit tests. |
JUnit 4 has dropped the strict naming conventions and inheritance hierarchies of old, in favor of the streamlined flexibility of Java? 5 annotations. In this tutorial, a supplement to his popular series on code quality, testing fanatic Andrew Glover shows you how to leverage the new features enabled by annotations, including parametric tests, exception tests, and timed tests. He also introduces JUnit 4's flexible fixtures and shows you how to use annotations, rather than suites, to logically group tests before running them. The tutorial includes several sample tests run in Eclipse and instructions for running JUnit 4 tests in older, incompatible versions of Ant. |
Introduction This article is for VisualAgeĀ© for JavaTM users who want to unit test their EJBs and develop test cases for them. The article is based on VisualAge for Java 3.5.3 and JUnit 3.7. The article describes JUnit, the difficulties in unit testing EJBs, and the steps involved in developing test cases. |
Note: The changes to the framework are quite bleeding-edge. Although the broad outlines of JUnit 4 are clear, the details can still change. This is meant to be an early sneak peek at JUnit 4, not the final word. |
Assertion Extensions for JUnit (JUnitX), an extensions package for the JUnit framework, is available for download from alphaWorks (see Resources). It provides the required implementation of many common complex assertions. Rather than write a complex JUnit test case for an assertion, you can call a JUnitX method to make that assertion from the same context -- with no additional setup. JUnitX also asserts that it functions as documented by including its own JUnit self-test suite. This reassures you that JUnitX is making its assertion according to the JUnitX documentation; if a unit test fails, you know it's the software code unit that has failed, not the JUnitX test implementation asserting a false failure. |
Thanks to Jython, a Java platform implementation of the Python programming language, the answer is a resounding "yes!" (If you're not familiar with Jython, you should brush up before going further in this article; see the links in the Resources section below for more information.) Using the power and elegance of Jython, you can maintain a script that scours your filesystem, searching for classes that match a certain pattern, and dynamically build a JUnit TestSuite class. This TestSuite class, like any other statically defined class, can be easily debugged using your favorite debugger. (The examples I'll use in this article will assume use of the Eclipse IDE; however, the techniques I describe here will work with most other IDEs without much modification.) |
This Ant target runs the JUnit 4.5 test cases using the NumberCruncherTestSuite45.java class discussed earlier. The output is plain text that is echoed to the console. There are many fancier options for saving the output of extensive test suites to various output formats, such as XML, and even for applying XSL stylesheets to the output for control over the appearance of the report that is generated. |