Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Programming Books Media Bug Java Book Reviews IT Technology

Pragmatic JUnit Testing 118

Will Gwaltney writes "The Pragmatic Programmers have done it again. This time it's with volume 2 of their Pragmatic Starter Kit series, Pragmatic Unit Testing in Java with JUnit. In the friendly, accessible style we've come to expect from Andy Hunt and Dave Thomas, the book provides a gentle introduction to unit testing in general and the JUnit testing package in particular. Of course, by the time you've read through the introduction you're hooked, at which point Andy and Dave give you enough information to make you not just a good unit tester, but a better developer to boot." Gwaltney offers this disclaimer: "I know both authors and was one of the proofreaders for this book. I have no financial stake in either the book or their company." With that grain of salt, read on for the rest.
Pragmatic Unit Testing in Java with JUnit
author Andrew Hunt and David Thomas
pages 159
publisher The Pragmatic Bookshelf
rating 10
reviewer Will Gwaltney
ISBN 0974514012
summary Unit Testing introduction, tutorial, and developer's guide

What's the Approach?

You can go a long way in the unit testing world with this book. It's a great starter guide for learning about unit testing; the first chapter has several small sections which answer many of the questions a novice might have about the subject, including some of the most common objections to unit testing. Then the book launches into a detailed user guide to the JUnit package, including some useful but lesser-known topics like writing your own custom asserts.

After you've got the basics down, the book spends several chapters drilling into the concepts, considerations, and best practices for writing good tests. This section of the book is quite practical, and is where the true worth of the book comes out. Any developer who reads this section will come away better for it even if they never consistently write unit tests. It's amazing how many testing issues turn out to be development issues at their core; this section of the book points some of them out. Simply being aware of these issues can help you to avoid a number of common pitfalls.

Finally, the book discusses common unit testing problems and their solutions. This section is a lot of fun because of the anecdotes that Andy and Dave include; unfortunately some of them I recognized from my own experiences as a developer. (What, me do that? No, uh, of course not!)

Who's it For?

This book is primarily for developers (and testers who are intimately involved in the development process), since unit testing per se is primarily a developer task. Depending on the organization of the software shop, by the time code gets to a formal testing or QA group it's probably too late to apply unit testing methods effectively. (Note I said unit testing methods here.) The book is ideal for the unit testing novice, and there's a lot of good information here for more advanced developers to ponder.

The book is targeted at those who want to learn "how to think about tests, how testing affects design, and how to handle certain team-wide issues you may be having" (from the Preface). In particular the book is an excellent source of information for those developers who have recently moved into the Java area and are looking for a good testing framework.

No matter what your role in the development process, this book can help give you a fresh perspective into unit testing and related issues. It prods you to think about issues that perhaps you hadn't considered before.


As you can probably tell, I like the Pragmatic Programmer writing style. It's informal and friendly without being chatty or wordy, and the main text moves along well. More technical discussions are reserved for sidebars, and there are "Joe Asks..." sections throughout the book that anticipate questions that Joe Programmer might ask about the current topic.

The examples in the book are excellent. Many books err on the side of code snippets that don't have enough context to be understandable, or multi-page code extravaganzas that bury the details of the topic at hand under mountains of cruft. I found the examples here to give just the right amount of detail to understand what's going on. And the source for all the examples is available from the author's web site.


What this book is not is a reference manual for JUnit. The book doesn't include a javadoc listing for the JUnit package, nor does it have a section that digs into JUnit's internals. This is not necessarily a Bad Thing because that information is available from the JUnit web site, but it does bear mentioning.

If there was anything I found to complain about it was the use of acronyms in the concepts section of the book. I'll admit right here that I'm no lover of acronyms, so I felt that using things like Right-BICEP, CONNECT, and A-TRIP as mnemonics for the concepts was a bit over the top. (Read the book to see what I mean.) However, I have to admit that they help me remember the concepts discussed, so I guess they do their job (grumble).

Why Should I Read this Book?

If you hate testing, this book will very probably change your mind, and you'll have fun in the process (the stories are great!). And even if you still hate testing after you've finished the book, you will have enhanced your development skills enough to be able to delude yourself that testing isn't necessary for you (well, maybe not that much). At the very least, this book will make you aware of the various issues that proper testing can expose and maybe help you try to avoid them. By shining a light into these areas, it can still make you a more effective developer... maybe effective enough to realize how much more solid your work could be with this type of testing coverage.

If you love testing, this book will remind you why you began the love affair. Your love will be strengthened and deepened, and the tests you write will undoubtedly get better, too.

For Java developers specifically, this book will get you started writing JUnit tests painlessly and effectively and will take you a long way down the road to unit test proficiency. It will give developers in any language quite a bit to take "back to the terminal" regarding design and process as well as testing. An excellent and much needed book.

Like volume 1 of the Pragmatic Starter Kit series ( Slashdot Review), this book is available from the Pragmatic Programmer website. The printed version is $29.95 and there's a PDF version available for $20.00. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Pragmatic JUnit Testing

Comments Filter:
  • I've read both books (Score:2, Informative)

    by Pingular ( 670773 )
    and I prefer this [] one. Just my opinion though.
  • by tomblackwell ( 6196 ) on Monday March 01, 2004 @04:02PM (#8432864) Homepage
    It might be wiser to trust someone slightly more removed from the creators and creation of this book with respect to its utility.
  • by kompiluj ( 677438 ) on Monday March 01, 2004 @04:03PM (#8432882)
    Jeez, I like being both pragmatic and extreme when I use JUnit.
  • by plover ( 150551 ) * on Monday March 01, 2004 @04:03PM (#8432886) Homepage Journal
    I guess the question is, are the concepts in the book presented generically enough such that it would port (for a sufficiently loose definition of port) to another framework such as CppUnit?
    • by mrob2002 ( 564229 ) * on Monday March 01, 2004 @04:17PM (#8433028)
      They certainly are. Most of the book is about how to write good unit tests, e.g. test the boundary conditions, and how to think clearly about what the boundary conditions are. I took enough away to start using nUnit successfully (nUnit is a framework for .Net unit testing). I've found unit testing extremely useful in day to day development, and this book taught me how. It's also available in PDF from the authors' web site if you prefer that format.
      • Thank you, I'll have to add this book to my ever-expanding "In" queue of books. I've needed to "automate" my testing for some time now and while JUnit seems like the right way to go, it doesn't do much for a C++ project. But I've been reading up on CppUnit [] and I think that's the way I'll go from here.

        Thanks again.

        • I'd also suggest looking at unit++ for your unit testing needs in any c++ project. Very easy to use, and just seems like the c++ way of doing things. Some of the "ports" of junit to c++ still seem to javaish for my liking.
          • I've used CppUnit in testing complex code, and the big problem in C++ land is that a catastrophic failure of one test (i.e. pointer trouble) can contaminate the process so badly the remaining tests fail. Java tends to catch up on such things faster, so contaminates the other tests less often. This makes it harder to write test suites that rigorously try bad things and which all run happily. But on the positive side, once you have done that you end up with a nicely robust C++ program, as you fix all the poin
    • by caseydk ( 203763 ) on Monday March 01, 2004 @06:50PM (#8434518) Homepage Journal

      Actually, I caught a presentation from Andy Hunt early last month and he talked about this directly.

      They're releasing a version for C# shortly and they have the intent of releasing the book for a few other languages.

      The most interesting part is that he told us that they're working to keep the language-specific content seperate from the main text. Therefore, they can write the applicable stuff in a given language and then LITERALLY run a makefile to make the next book.

      Pretty sick (yet, pretty sharp), huh?
  • JUnit? (Score:5, Funny)

    by Lando Griffin ( 698606 ) on Monday March 01, 2004 @04:04PM (#8432894)
    Isn't that 50 Cent's group?

    "JUnit, yeah, we'll take your ass out. JUnit, yeah, that's what we're about!"

    • G-Unit. (Score:4, Funny)

      by bad enema ( 745446 ) on Monday March 01, 2004 @04:14PM (#8433000)
      But I applaud your attempt.
    • What's sad is, I clicked the topic specifically to write

      "J-J-J-J-J-J-J J UNIT!"

      Wonderfully, I wasn't the only one with that thought.
    • Re:JUnit? (Score:1, Interesting)

      by Anonymous Coward
      No, Junit was a minor Egyptian goddess. So minor, in fact, that I can't find any specific information about her apart from this image [] (warning: contains nudity).

      Personally, I'll never use this thing because I used to work with somebody who was sure that it didn't matter if his code ever worked, or if it was documented or if it did what it was supposed to do, as long as he wrote enough tests for it. Of course, anybody who didn't agree with him was automatically anti-testing and thus responsible for the proj
  • by grub ( 11606 )

    Pragmatic JUnit Testing was the quantum leap I needed. Because of Pragmatic JUnit Testing, the lateral shift to JUnit was perfect. It wasn't a complete shock thanks to Pragmatic JUnit Testing. Overall I'd say it wasn't so much a complete paradigm shift but thanks to Pragmatic JUnit Testing, it helped me think outside the box.

    Three cheers for Pragmatic JUnit Testing!!

    Hip hip.. HOORAY!
  • ...was a good one [] for learning about CVS.

    Especially helpful was a small appendix which listed various recipes; i.e., the series of 3 or 4 steps necessary to merge a bugfix from one branch to another or whatever. I always forget the order of those cvs -j options...
  • Sigh :( Such is the life of the geek...
  • extreme programming (Score:2, Interesting)

    by tijnbraun ( 226978 )
    Is Junit any way linked with extreme programming []? It sound that their goals are quite identical. However their ore information []more informationsection doesn't mention JUnit anywhere.
    • by Abcd1234 ( 188840 ) on Monday March 01, 2004 @04:23PM (#8433087) Homepage
      Err, JUnit and Extreme Programming are really pretty orthogonal. XP, which is a programming methodology, preaches the idea of writing unit tests before writing code. JUnit is a unit testing framework for Java. Therefore, JUnit can be useful tool in the practice of Extreme Programming, as it is designed for the express purpose of simplifying the creation of unit tests.
    • by plover ( 150551 ) * on Monday March 01, 2004 @04:24PM (#8433101) Homepage Journal
      Only in that extreme programming is a test-centric philosophy that requires you to continually recompile/test while developing.

      My understanding of JUnit is that it's a test framework that simplifies running all the tests you've developed in conjunction with a project. So, if you use the JUnit foundation to build your unit tests, theory says that before turning your code over to the QA teams you'd run JUnit over the whole ball of wax to make sure you aren't sending out something stupidly broken.

      But your question: "is JUnit linked with Extreme Programming" is a lot like asking if C++ is linked with Borland or Microsoft. If you're into extreme programming in Java and testing with JUnit, then yes, they're linked. And if you're into extreme programming in Java, then you're probably already using JUnit.

    • Although I think that XP has some valuable ways of bugs to be found. My link should have been "more information" [].
      The ore of bad programming can be probably found elsewere.
    • Is Junit any way linked with extreme programming? It sound that their goals are quite identical. However their ore informationmore informationsection doesn't mention JUnit anywhere.

      Well, JUnit's website [] has the title, "JUnit, Testing Resources for Extreme Programming".
    • by nimblebrain ( 683478 ) on Tuesday March 02, 2004 @04:56AM (#8438513) Homepage Journal

      Unit testing does not require eXtreme Programming. On the other hand, eXtreme programming does require unit testing. We've studied XP's practices, and they seem to be roughly broken into two groups: programming for ever-changing requirements, and quality assurances (refactoring, unit testing) to make sure the code doesn't fall apart.

      As many anti-XP pundits will point out, unit testing is worth applying to any project that you can apply it to, and there are precious few that can't.

      I do a lot of framework-level programming, and I must say that stability, as well as my confidence in the code, has increased substantially from putting unit testing into the mix. Some folks advocate TDD (Test-Driven Development []) in the canonical sense (test first), but I find that the completely up-front test creation works in practice only when you have rock-solid easy-to-translate-into-source-code checklisted requirements. I compromise, and build the tests after the interfaces, rough algorithm and rough support objects have been put together.

      Here are a few things I've learned over my unit testing experiences:

      • If the individual test methods start to get beefy, spin off the pieces you can into English-sounding methods on their own, especially if it's something you find yourself using in multiple test methods. Methods for creating test objects and comparing the test results are usually prime candidates.
      • If you have a facility to use generics in your programming, use it for anything you've had to do exactly the same 3+ times over - you can cover off the generic with a single unit test module
      • Classes are easier to test if you make liberal use of interfaces or abstract base classes - this lets you create classes for use by the test that implement extremely rudimentary functionality (instead of asking a web service for a value, it returns "1", or gives back an error) and/or that can be used as counters/loggers for the number of times and with what parameters the services are requested.
      • Negative testing is important - if you don't explicitly test what out of bounds, null or otherwise invalid input parameters and states do to your object, you're leaving yourself open to a host of "undefined behaviors" which can cause bugs.
      • For unit testing lower-level classes, you'll often find that a unit-test-per-method works well. For unit testing higher-level classes, you'll find yourself keeping the class the same, but the test methods will vary the data that gets fed into it.

      I haven't figured out a good means to unit test concurrent code, but you can often stack the deck for fast-running processes by adding in delays in key spots to extend the exposure to weak spots.

      Unit testing isn't for everything. It coughs and sputters a bit when you don't have full control over the environment (databases, sockets, network configuration, user interaction). You can shoehorn it in, but it's usually better left for the likes of regression testing and functional integrated testing [].

      For a quick start to functional testing, we've started test-driving TestComplete [] at our office; it's proven itself to be a capable tool (our lead QA man has put up a sign on the computer entitled, "I am Q-Tron; I Test Software While Mere Mortals Sleep" - it has been testing out communications while he sleeps :)

  • by Anonymous Coward on Monday March 01, 2004 @04:36PM (#8433221)
    Next week, Steve Ballmer reviews "The Road Ahead"
  • Question on the book (Score:4, Interesting)

    by pcraven ( 191172 ) < minus caffeine> on Monday March 01, 2004 @05:46PM (#8433958) Homepage
    I've found it very difficult to write good tests on applications that were web-based, and highly dependent on the data. Does this book have good solutions for these problems?
    • by congaflum ( 754687 ) on Monday March 01, 2004 @06:35PM (#8434378)
      It does offer some solutions and advice to those, although I'd have liked to see more of the book devoted to it. I think most folk can easily see the benefits of unit testing when shown simple examples (like writing tests for a linked list or a temperature converter or something), but it takes a fair bit more effort to learn how to apply tests to "real world" code.

      From what I've learned so far, there are 2 main things that'll help you write unit tests for these sorts of situations: one is to mercilessly refactor your code as you go, and soon you'll probably find it naturally becomes easier to test. Seperate any database code from the application logic, for example, and you'll probably find that the application logic becomes pretty easy to test.

      The second thing is mock objects. The typical example of these is (again) database code. By making a little mock implementation that only *looks* like it's really writing to a database you can often then test other parts of your code without having the hassle of setting up sample data, cleaning it back out afterwards and so on. In web apps, you may find it handy to have a mock implementation that pulls page requests, effectively pretending to be the browser.

      One other thing, which sounds a bit smug but is actually very true: if you start out writing tests from the beginning of a project, it will probably remain easy to test. On the other hand, if you take an existing codebase and try to retrofit tests onto it, it's more than likely that you'll have to rearrange a lot of code in the process... Cheers.
    • I asked this very same question a few years back in an Extreme Programming class. The answer we got to after discussion was something like:

      Refactor the design to handle the state of a transaction in a pluggable way; then create test transaction objects (that implement an abstracted transaction interface) and use those as part of the testing framework. That way the tested code is isolated from the state of the database.

      This really intrigued me as it turns the "UI at the top, db at the bottom" model insid
    • Junit in action covers other unit testing frameworks that address what you're looking for including HttpUnit, Mock Objects, Cactus (which even does in container testing) and other related technologies. If you are trying to use J2EE and unit test, this is a fantastic book. The coauthor Ted Husted, is even one of the committers for the struts project.
  • by Anonymous Coward on Monday March 01, 2004 @06:41PM (#8434435)
    Responding to the post above, there are a number of 'hidden benifits' to writing Unit tests for Real Programmers (and not Teacher's Assistants).

    1) It's fun (sad but true). I write my test cases first, and that gives me a chance to challenge myself. I'll try and write tests that are very comprehensive or hard to pass (but only if they adhere to the specification). I then hide the tests while I implement the code to see how much I remembered.

    2) It helps me seperate the notion of System code from Client code. This is pretty important because I'm often both the system architect and the client coder, and it's often hard to keep the two distinct when you're doing both.

    By writing the tests first, you are forced to think of the (unwritten) code as a client of the system. You ask yourself, 'How should this module work? What are the most simple and logical interfaces?' You then write code to those interfaces, and end up with clean architecture. You then implement the code to pass the tests.

    While that doesn't sound revolutionary, I find that without tests I have a tendency to let the logic dictate the interface. For example, I find myself thinking, 'this method would be really efficient if rather than receiving an abstract widget, it took 4 int args' (or something like that).

    There are some other benefits to Unit testing (code stability, confidence, etc), but those two were surprising 'discoveries' when I started unit testing.
  • by dsplat ( 73054 ) on Monday March 01, 2004 @09:37PM (#8435899)
    Kent Beck's book Test-Driven Development does a nice job of presenting where unit testing fits into Extreme Programming. It comes off as a bit of a cookbook and some of the examples are in Smalltalk, but even so I consider it a valuable addition to my bookshelf.

A verbal contract isn't worth the paper it's written on. -- Samuel Goldwyn