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.
I've read both books (Score:2, Informative)
The first book in this series.... (Score:5, Informative)
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...
Re:Is this book good for C++ programmers, too? (Score:5, Informative)
Re:extreme programming (Score:5, Informative)
Re:extreme programming (Score:5, Informative)
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.
Re:Java (Score:5, Informative)
Here's an example of one of the PMD JUnit tests that checks the command line option processing: and another that makes sure that an Exception is thrown in another case: When I make a code change, I just rerun all the tests to make sure I didn't break anything. If someone reports a bug, I add a test so that bug won't reappear. Sweet.
Re:Unit tests are a bad idea (Score:2, Informative)
where the whole unit testing idea falls down is when you have things you can't unit test like jsps and servlets, these require much more complex testing methods.
Re:Unit tests are a bad idea (Score:5, Informative)
They went so far as to give us a few test cases (and if we didn't pass those test cases, we got a zero).
In fact, most of the grading process was to have their automatic system compare the output of our solution with the reference solution...
That said, the TAs were known to be lazy and I don't think anyone ever actually read our comments. I found this out when my solution differed slightly from what they expected (you had to do something different than they expected to direct the output to a file, namely java SomeProg > output, which was WELL commented...) and they couldn't figure it out... (hell, they didn't understand what that DID when I talked with them...)
So I can believe that you're a TA, but beyond that...
Re:Is this book good for C++ programmers, too? (Score:2, Informative)
Thanks again.
Re:Is this book good for C++ programmers, too? (Score:4, Informative)
Re:Question on the book (Score:5, Informative)
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.
Re:Question on the book (Score:3, Informative)
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 inside out. I've never tried it on anything larger than a little app; it worked well there but I don't think it would scale to a complex transactional application, especially if transactions aggregate or show other dependencies.
(Advice) (Score:3, Informative)
Do unit testing. Do simple coding. Do it for you. It's good for your soul. It'll save your career.
Case in point - I was working on ASP pages that get user ID/password information from a db before validating to the next layer. I refactored the entry page so that I could test all the pieces parts since we have different clients who log in through the same page and get taken to other places. Anyhow, I typed in our demo account and password and got in - had about four tests... so then I tried four different variations on the password, camel case, and an extra space at the end thinking it would pass. Wrong. The new tests all bombed and let the person in. Why? Because SQL is set by default to be case-insensitive, and the code only checked to see if there was a matching username/password combination in the table. One line of code checking the actual password coming back fixed a bug we had in the system since inception. And who knows what else is in there.
If it doesn't fit on a screen, then break it up or throw it away. It's not extreme - it's the only way to make sense of a large system. If you write code at that level, you only need Javadoc to tell why you wrote the story the way you did...
You'll be much happier. Ignore the TA from Harvard and make yourself better. You don't need to be extreme to do so.
J.