I'm a developer who works for a large company. Most of our testing is done by business analyst before it is moved to production. Can anyone tell me how I could benifit from a book like 'Pragmatic Unit Testing'.
The testing done by your business analyst is great, but it isn't unit testing. Unit testing is testing done by developers for developers. It doesn't test the overall functionality of an application. Instead, it focusses in on methods and classes, making sure that they do what we mean them to do. We do unit testing because otherwise we're building code on a shaky foundation: unless you can rely on a layer of software, building more software on top of it is a recipe for disater. If bug pops up, you can't be sure if it was in the stuff you'd just written, or in the stuff that it calls, or in the stuff that that lower level calls, and so on. In effect, testing goes from being a linear exercise to an exponential one. Think of it this way. Your sales tax calculate has stopped working. If you last tested it 2 minutes ago, and it worked fine then, then the culprit is likely to be the code you wrote since. It'll be easy to look at those 5 or so lines and track down the problem. If on the other hand you test only at the end, then you have no idea where in your system the sales tax problem is, and you'll need to fire up your debugger and step through, a painful exercise. I can honestly say I haven't used a debugger in years.
Some more advantages of unit testing I see: - because unit tests are more fine grained, they can help in localising a bug. With other words: a system test will tell you *that* there is a bug - a unit test *where* the bug is. - some forms of bug are much easier to find by white box testing (that is, testing with knowledge of the code), for example by testing boundary conditions. Your business analysts simply can't do this. - writing unit tests can also have a positive effect on the design, as only a reasonably decoupled design is well unit-testable.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
My conclusion is that *** Unit testing for each unit that build up the whole system, while Business Testing is for the whole system that is supposed to be work as specified by the functional specification....
If you have't touched a debugger in years, then I will surely buy this book. Not having touched a debugger in years could be symptomps of other things, first which comes to mind is that of not programming any serious stuff in years.
There's no place like 127.0.0.1
Joined: Mar 12, 2001
That makes alot of sense guys. And I definately agree with David.
I'm not sure I agree 100% with David. When I used to program with Visual C++ and/or VB (ugh) I did quite a bit of using a debugger. With Java, I've found that there is not as much need for debugger because the Exception architecture is so well constructed. With stack traces (and using a logger), I find that I can just run everything through ant and get all the info I need on state and flow of control without a debugger. And actually, doing that forces you to write better programs - because you have to think about exactly how you'll bubble up the exceptions and where they'll be handled. And of course it forces using SomeExactException instead of the general (and much less useful) Exception. [ February 18, 2004: Message edited by: Robert Paris ]
Originally posted by Robert Paris: With Java, I've found that there is not as much need for debugger because the Exception architecture is so well constructed.
Obviously the exception stack trace helps you notice NullPointerExceptions etc., but most often it won't tell you where the real source for that NullPointerException is -- i.e. the piece of code that should've returned something else but returned a null...
Originally posted by David Attard: If you have't touched a debugger in years, then I will surely buy this book. Not having touched a debugger in years could be symptomps of other things, first which comes to mind is that of not programming any serious stuff in years.
People who write books about programming should be programmer, and Andy and I work hard to keep current. We spend a fair amount of time writing large, commercial applications.
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Joined: Jul 11, 2001
Originally posted by Robert Paris: I'm not sure I agree 100% with David. When I used to program with Visual C++ and/or VB (ugh) I did quite a bit of using a debugger. With Java, I've found that there is not as much need for debugger because the Exception architecture is so well constructed. With stack traces (and using a logger), I find that I can just run everything through ant and get all the info I need on state and flow of control without a debugger.
Exceptions are not the only (or even most common) bugs in programs. Imagine your program prints bills, but is always off by some amount. No Exception occurs, so you really need a different technique, so it seems to me. And even *if* there is an exception thrown, it will probably only be thrown when a specific path in the program is executed. That is what the tests will do for you: automatically, reliably and repeatedly execute specified paths in your program and build a report on wether unexpected things happened. [ February 18, 2004: Message edited by: Ilja Preuss ]
I am just starting out in Java Cert land and come from C/C++ where debugging is the Nasty Norm! So I thought I'd chime in on the less debugging thing w/ test driven dev. Rob Paris said
With Java, I've found that there is not as much need for debugger because the Exception architecture is so well constructed
Perhaps minimal debugging is more common in Java due in part to JUnit, but also because Java lacks pointers and expresses some clarity in some of its strictness of structure i.e. in exceptions. This strictness of structure may be inhibiting - consider experience expressed in the excellent JACE paper, which I hope is not too dated: http://www.cs.wustl.edu/~pjain/java/java_notes.html
A few people have commented on Java needing less debugging than other languages. I find it more interesting that significantly less debugging is needed when using junit than when just programming in java. Junit gives helpful error messages like "expected 3.5 but was 3." This eliminates a lot of debugging because you already know some values.