Slashdot Mirror
Pragmatic JUnit Testing
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.
Slashcode uses FAG-matic testing.
Thanks for listening to this first post attempt.
IS FOR FAGETS.
and I prefer this one. Just my opinion though.
When anger rises, think of the consequences.
Confucius (551 BC - 479 BC)
What's so damn pragmatic about it? FP
It might be wiser to trust someone slightly more removed from the creators and creation of this book with respect to its utility.
Jeez, I like being both pragmatic and extreme when I use JUnit.
You can defy gravity... for a short time
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?
John
"JUnit, yeah, we'll take your ass out. JUnit, yeah, that's what we're about!"
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!
Trolling is a art,
Juh-juh-juh Juh-juh-juh JAY-UNNNITT /me flashes gang signs
my UID is lower than yours
- my userid is lower than yours
...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...
The Army reading list
Sigh :( Such is the life of the geek...
The revolution will not be televised.
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.
Moderators, express your consent by modding this offtopic
But I applaud your attempt.
I "test my unit" several times a day!
So what does a JUnit call look like
d Result(4)r mat.setLocaleFractionalSeperator('.')r matter(format)
JUnit unit = new JUnit.TestFramework.SimpleTest()
unit.setExpecte
unit.setPassMessage('Okay, exponention works...')
unit.setFailMessage('Uh oh...')
NumberFormatter format = new NumberFormatter()
format.setDecimalDigits(1)
fo
unit.setFo
unit.runTest(Math.pow(2))
Seriously, kids, java is bad for you...
TODO: Something witty here...
I guess I'm shallow like that.
I'm a teaching assistant (TA) at Harvard University, and I mark a lot of Java code as part of a job that supports my PhD studies. Code submitted to me with unit tests face an automatic 5 mark penalty, before i even begin marking. There are several reasons for this.
- Extra code == extra bloat. The unit test code is submitted as an extra class file, which means there is one more thing that I have to read over before I can judge their code on its merits. I find that unit tests are a pain to compile, normally found deep in a directory structure where they make little sense.
- Too much documentation. People who submit unit tests generally document the interfaces using javadoc, which just increases the amount of reading I have to do before I can assign a mark. HTML as a documentation format is stupid. There is nothing wrong with submitting code with comments at the start of a function or method and leaving it with that. If the code needs documentation because it is doing something non-obvious, it is time to rethink the code.
- Unit tests are written with no extra skill than the code they test. Unit tests induce a level of confidence in the programmer that their code works as a black box. This is a bad idea. Programmers should understand why each and everyone of their modules works the way it does, not assume that everything is well because it passes some rudimentary test that was created with the same skill level as the rest of their code.
As you can see, I'm against unit testing. I've tried my hardest to get the profs to teach i386 assembly and then C so that students understand how a computer works, but to no avail. If we are to regain our jobs from the Indians, we must be more professional coders.junk characters? what the fuck is your problem? are you some sort of character bigot? i mean, really. what the fuck is wrong with - and ( and all their friends? are they somehow inferior to e and a and such? do you hate niggers, boy? is that your goddamned problem?
Is that Dave Thomas, founder of Wendy's or Dave Thomas aka Doug McKenzie?
I met Andy Hunt's brother Mike at a social event once, a brilliant man indeed.
I don't need no instructions to know how to rock!!!!
Next week, Steve Ballmer reviews "The Road Ahead"
What the fuck is an "ass-spelunker"?
See subject.
And no where in there does it talk any thing about Hamburgers or about adoption.
Infact, the only thing I come to expect from Dave Thomas is that he's pushing up daises.....
Does slashdot really matter? Does life really matter?
It's all perspective.
It is the Dave Thomas from the old SCTV series.
;)
So take off, hoser
But what about those of us who hate testing, and it's our job?
My friend wrote it! And I proofread it! And I'm submitting it to you! Strangely, I really liked it! Really!!
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?
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.
For projects that never ship. If your working in some massive back office, on some huge accounting app due buy late 2008, unit testing is a great way to occupy your time. Go ahead get them code coverage numbers up to 100%. Spend hours and hours writing tests for problems that will probably never occur. Brag about how perfect your code is at the water cooler, because you have so many unit tests, it's proved to be prefect. Ride that green bar for all its worth comrade!
Dismiss management concerns over how long the project is taking; after all perfect code takes time! You can prove to management that the code is great by all of the wonderful unit tests you've written.
But pray you don't ever ship the code, it must never go into production. Because if it does you have to explain why your perfect code has bugs, just as many as code without unit tests. And why your application is significantly slower then non unit tested apps.
Unit testing just wastes time.
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.
The net will not be what we demand, but what we make it. Build it well.
It's one huge, stupid hyperbole until you get to "And why your application is significantly slower then non unit tested apps.", which is a straight-out lie.
Don't worry you young students... the PHB's don't read your code, and your coworkers will hate you for writing it after you're gone.
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.
This space for rent.
At least, THATS WHAT SHE SAID!!!! (in Russian, no less!!!)
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:
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 :)
Binary geeks can count to 1,023 on their fingers
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 pointer defects it throws.
Oh, the other problem is catching and reporting things like pointer errors; CppUnit is set up to only catch std::exception subclasses.
...the Pragmatic Programmers have farted again.
Head for the hills, party people!