|
Pragmatic Unit Testing in C# with Nunit (Pragmatic Programmers)
|
| Price: |
8 new or used available from £23.96
Average customer review:
Product Description
Learn how to improve your C# coding skills using unit testing. Despite it's name, unit testing is really a coding technique, not a testing technique. Unit testing is done by programmers, for programmers. It's primarily for our benefit: we get improved confidence in our code, better ability to make deadlines, less time spent in the debugger, and less time beating on the code to make it work correctly. This book shows how to write tests, but more importantly, it goes where other books fear to tread and gives you concrete advice and examples of what to test--the common things that go wrong in all of our programs. Discover the tricky hiding places where bugs breed, and how to catch them using the freely available NUnit framework. It's easy to learn how to think of all the things in your code that are likely to break. We'll show you how with helpful mnemonics, summarized in a handy tip sheet (also available from our www.pragmaticprogrammer.com website). With this book you will:
- Write better code, and take less time to write it
- Discover the tricky places where bugs breed
- Learn how to think of all the things that could go wrong
- Test individual pieces of code without having to include the whole project
- Test effectively with the whole team
Product Details
- Amazon Sales Rank: #654615 in Books
- Published on: 2004-04-01
- Original language: English
- Number of items: 1
- Binding: Paperback
- 176 pages
Editorial Reviews
From the Publisher
Improve your C# coding skills using unit testing: it's really all about coding, not testing. This book shows not just how to test, but what to test. Discover the tricky hiding places where bugs breed, and how to catch them using NUnit. You don't need to adopt Extreme Programming, or Test-Driven Development in order to reap the proven benefits of unit testing, the pragmatic way. Volume II of the Pragmatic Starter Kit.
About the Author
Andy Hunt and Dave Thomas have more than 50 years combined experience, developing software for clients around the world. For the last 10 years they've been working together as The Pragmatic Programmers, helping clients write software and improve their development processes. They are authors of the best-selling The Pragmatic Programmer, and have written several other books. They speak at conferences globally, and are editors of IEEE Software's "Construction" column. Andy Hunt and Dave Thomas have more than 50 years combined experience, developing software for clients around the world. For the last 10 years they've been working together as The Pragmatic Programmers, helping clients write software and improve their development processes. They are authors of the best-selling The Pragmatic Programmer, and have written several other books. They speak at conferences globally, and are editors of IEEE Software's "Construction" column.
Excerpted from Pragmatic Unit Testing in C# with NUnit by Andy Hunt, Dave Thomas. Copyright © 2004. Reprinted by permission. All rights reserved.
Chapter 1 Introduction
There are lots of different kinds of testing that can and should be performed on a software project. Some of this testing requires extensive involvement from the end users; other forms may require teams of dedicated Quality Assurance personnel or other expensive resources.
But that’s not what we’re going to talk about here.
Instead, we’re talking about unit testing: an essential, if often misunderstood, part of project and personal success. Unit testing is a relatively inexpensive, easy way to produce better code, faster.
Many organizations have grand intentions when it comes to testing, but tend to test only toward the end of a project, when the mounting schedule pressures cause testing to be curtailed or eliminated entirely.
Many programmers feel that testing is just a nuisance: an unwanted bother that merely distracts from the real business at hand—cutting code.
Everyone agrees that more testing is needed, in the same way that everyone agrees you should eat your broccoli, stop smoking, get plenty of rest, and exercise regularly. That doesn’t mean that any of us actually do these things, however.
But unit testing can be much more than these—while you might consider it to be in the broccoli family, we’re here to tell you that it’s more like an awesome sauce that makes everything taste better. Unit testing isn’t designed to achieve some corporate quality initiative; it’s not a tool for the end-users, or managers, or team leads. Unit testing is done by programmers, for programmers. It’s here for our benefit alone, to make our lives easier.
Put simply, unit testing alone can mean the difference between your success and your failure. Consider the following short story.
1.1 Coding With Confidence
Once upon a time—maybe it was last Tuesday—there were two developers, Pat and Dale. They were both up against the same deadline, which was rapidly approaching. Pat was pumping out code pretty fast; developing class after class and method after method, stopping every so often to make sure that the code would compile.
Pat kept up this pace right until the night before the deadline, when it would be time to demonstrate all this code. Pat ran the top-level program, but didn’t get any output at all. Nothing. Time to step through using the debugger. Hmm. That can’t be right, thought Pat. There’s no way that this variable could be zero by now. So Pat stepped back through the code, trying to track down the history of this elusive problem.
It was getting late now. That bug was found and fixed, but Pat found several more during the process. And still, there was no output at all. Pat couldn’t understand why. It just didn’t make any sense.
Dale, meanwhile, wasn’t churning out code nearly as fast. Dale would write a new routine and a short test to go along with it. Nothing fancy, just a simple test to see if the routine just written actually did what it was supposed to do. It took a little longer to think of the test, and write it, but Dale refused to move on until the new routine could prove itself. Only then would Dale move up and write the next routine that called it, and so on.
Dale rarely used the debugger, if ever, and was somewhat puzzled at the picture of Pat, head in hands, muttering various evil-sounding curses at the computer with wide, bloodshot eyes staring at all those debugger windows.
The deadline came and went, and Pat didn’t make it. Dale’s code was integrated and ran almost perfectly. One little glitch came up, but it was pretty easy to see where the problem was. Dale fixed it in just a few minutes.
Now comes the punch line: Dale and Pat are the same age, and have roughly the same coding skills and mental prowess. The only difference is that Dale believes very strongly in unit testing, and tests every newly-crafted method before relying on it or using it from other code.
Pat does not. Pat "knows" that the code should work as written, and doesn’t bother to try it until most of the code has been written. But by then it’s too late, and it becomes very hard to try to locate the source of bugs, or even determine what’s working and what’s not.
1.2 What is Unit Testing?
A unit test is a piece of code written by a developer that exercises a very small, specific area of functionality of the code being tested. Usually a unit test exercises some particular method in a particular context. For example, you might add a large value to a sorted list, then confirm that this value appears at the end of the list. Or you might delete a pattern of characters from a string and then confirm that they are gone.
Unit tests are performed to prove that a piece of code does what the developer thinks it should do.
The question remains open as to whether that’s the right thing to do according to the customer or end-user: that’s what acceptance testing is for. We’re not really concerned with formal validation and verification or correctness just yet. We’re really not even interested in performance testing at this point. All we want to do is prove that code does what we intended, and so we want to test very small, very isolated pieces of functionality. By building up confidence that the individual pieces work as expected, we can then proceed to assemble and test working systems.
After all, if we aren’t sure the code is doing what we think, then any other forms of testing may just be a waste of time. You still need other forms of testing, and perhaps much more formal testing depending on your environment. But testing, as with charity, begins at home.
Customer Reviews
You won't learn much
This is my third attempt to review this book (for some reason if I give a product 5 stars my review goes straight on the site but if I criticise it then it never appears).
Anyway this book is overall quite poor, I definitely didnt learn much from it and it definitely isn't at the same level as the Pragmatic Programmer. I would recomment Test Driven Development: A Practical Guide, its written for Java but most of the information applies to .NET and its full of useful advice.
Poor
Dont be fooled into buying this book just because "The Pragmattic Programmer" was so good, this book is in no way in the same class and provides very little useful information. Test-Driven Development: A Practical Guide is far more useful (I know its for Java but that doesnt make much difference).
Lacks Any Depth
I was fooled into buying this because I liked "The Pragmatic Programmer" so much but this book is in no way up to the same level. Its quite poorly written, is very shot, repeats itself and gives you next to no useful information.
I recommend "Test-Driven Development A Practical Guide" over this anyday, I'm actually a .NET developer but the fact that it is in Java hasnt caused me any problems and I learned more in 50 pages of it than I did in "Pragmatic Unit Testing in C# with NUnit".
