• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Pragmatic Unit Testing??????????

 
Ronnie Phelps
Ranch Hand
Posts: 329
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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'.
 
Prag Dave
author
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Cheers

Dave
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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....
 
David Attard
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ronnie Phelps
Ranch Hand
Posts: 329
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That makes alot of sense guys. And I definately agree with David.
 
Robert Paris
Ranch Hand
Posts: 585
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Dave Thomas
Author
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Mike Winter
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34071
331
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic