







Pragmatic JUnit Testing 118
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.
Pros
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.
Cons
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.
Is this book good for C++ programmers, too? (Score:5, Interesting)
extreme programming (Score:2, Interesting)
Re:Unit tests are a bad idea (Score:5, Interesting)
> Extra code == extra bloat
Writing tests helps student understand their code and track down bugs. If you don't want students to submit tests, tell them not to.
> Too much documentation
What does JavaDoc - which the compiler discards - have to do with unit tests?
> Unit tests are written with no extra
> skill than the code they test
Don't throw the baby out with the bathwater. If a student is writing tests, at least he's trying to improve his code quality. You're a grad student; show him how to write better code _and_ better tests.
Re:Unit tests are a bad idea (Score:2, Interesting)
I cannot ever begin to express how amusing it is to hear a guy say that he wants professional coders and then complain that unit testing gives him more documentation to read. The horror!
That reminds me, I need to call up M$ and tell them that I want a patched version of XP that doesn't include any help documents. Real coders don't need documents.
If you have this TA, change your class now.
Re:Unit tests are a bad idea (Score:2, Interesting)
Your 1,2,3 are all faulty if applied to the working world. Which, by the way, is where real life is.
Your last sentence has a blob of irony in it. Can you spot it?
Question on the book (Score:4, Interesting)
Re:JUnit? (Score:1, Interesting)
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 project failing (nothing to do, of course, with the fact this guy had no idea what he was doing). Argh.
The company, you'll be glad to know, is out of business, so you'll never use that particular product, but the guy is alive and well corrupting code belonging to other companies.
Sorry, went on a tangent there, but 3 years later I still need to vent.
Re:Is this book good for C++ programmers, too? (Score:5, Interesting)
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?
There's another book occupying this niche (Score:5, Interesting)
Unit testing as quality control (Score:5, Interesting)
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 [testdriven.com]) 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:
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 [ucalgary.ca].
For a quick start to functional testing, we've started test-driving TestComplete [automatedqa.com] 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 :)