An Interview with Agitar's Alberto Savoia from JavaOne 2007

Although writing unit tests has become an accepted and highly valued developer best practice, developers new to unit testing still face several challenges. The first one is that development frameworks with testing as a core element tend to also require that developers follow additional coding practices not related to testing.

In this interview with Artima, Agitar founder Alberto Savoia explains that such rigid approaches are not required to enjoy the benefits of developer testing. To prove his point, Savoia penned a series of short, humorous essays, which he titled Testivus:

Testivus is developer testing for the rest of us. Even though practices like TDD or extreme programming have a lot of merit, we found that a majority of developers are not ready to embrace something so encompassing—and so dogmatic. Testivus is a take on a Seinfeld episode... [Editor's note: Seinfeld was one of the most popular television series in the U.S.] One of its precepts is "less testing dogma, more testing karma..."

Testing karma means, "Do good things to testing, and good things will happen to you." It makes more sense when you contrast it with testing dogma. Testing dogma says that you have to test this way, and only this way, don't do this, don't do that, etc. A lot of developers, by nature, like to explore... If you tell [developers] to do something this way, a lot of people are not going to do that. So you throw the testing baby out with the water, which is bad. Testing karma means [that] writing unit tests is a developer responsibility—do it, but don't just be too constrained by the "right" way of doing it. You don't want to be too dogmatic about it.

I created a booklet, The Way of Testivus. It's in the form an ancient, lost, Zen-like document from the "first-ever software start-up on record..." I wrote many epigraphs for this book, and one of them says, "Think of code and tests as one." What it means is that "When writing the code, think of the tests, when writing the tests, think of the code." When you think of code and tests as one, testing is easy, and code is beautiful...

The second obstacle to good testing practices is that developers, especially those facing a large existing code base, don't always have time to manually craft unit tests. A believer in automation, Savoia and his Agitar colleagues put together a free service, JUnitFactory, that generates JUnit tests from code submitted from a Web form or through an Eclipse plug-in:

We have a Web site called JUnitFactory. We automatically generate JUnit tests for you for free. There is an Eclipse plugin, and there is also a Web-based version. As long as you are not too concerned about exposing your code by sending it over the Internet, you can get unit tests for free. We have a big server farm, so you can get hundreds of tests in minutes, and start playing around with those tests. Even though lovely unit tests written by hand are better than the tests you can generate automatically, some tests are better than no tests... and this is a very good way to get started quickly.

Alberto Savoia, founder and CEO of Agitar discusses testing karma and the benefits of JUnitFactory.

What do you think of the role of automation in unit testing? To what extent do you trust tools to generate tests for your code?

Post your opinion in the discussion forum.

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the authors

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.