| Tuesday, December 18, 2007 | |
| | | A Developer's Perspective | |
 | Oscar Huseyin specialises in Java EE system consultation and development, primarily for the banking and finance sector. He's considered a tough leader in the Melbourne Java Community where he's been a practicing Software Engineer for the last 8 years. His interests are in OO Design, Patterns, Development Methodologies, Java Performance and Image Search. |
Unit Testing: How far to push the envelope?
By Oscar Huseyin
Over the years, I've read lots of commentary, white papers, best practice papers, and books on the topic of TDD. I've heard the rants of many TDD evangelists who preach about how total code coverage brings you closer to code quality perfection and how you've failed when you've not been able to achieve these goals. Sure, this is an extreme example of evangelical preaching, where in actual fact most of these individuals commonly drum down their hard line views of testing by using words like "pragmatism" and statements like "do what works best". But, why do l feel as if I've failed if l have not got 100% code coverage? It's because l, to some degree, shared some of the religious views about testing.
I'm now at a point where I'm beginning to rethink some of my beliefs about testing after many years in the trenches. So, I'm at the crossroads settling on a methodology that, l feel, works the best. What level of unit testing is really required to meet the business needs?
I'll start by analyzing two "special interest" projects to see the outcomes they delivered based on the business expectations.
First, let me talk about a project that was one extreme; no mandated position on unit testing. The project was highly successful, where the business expectations were met and exceeded. Donning my evangelist hat, I'd say the project outcomes were a fluke and it was a miracle that we were able to make any changes to the application without having a negative impact on functionality. Looking back, the project was definitely not a fluke; we made lots of changes to the application without any regressive impact. We knew our issues and had the right processes in place to gate-check the application functionality pre-release. For example, a week before each release, every developer had an area of expertise in the application which they would spend approximately a week testing the functional area and making any spot fixes as need be. We were not very clever about our testing methodology, but we delivered on time, on budget and exceeded customer expectations.
Now, let me tell a story of another, very different project - one that's in stark contrasts to the first one. This application had literally 98% code coverage. Unit tests, integration tests, front-end screen tests, watertight code reviews, continuous integration, nightly deploys; every agile practice and quality assurance process under the sun. Did the code meet the business expectations? Well, yes; but it was expensive. It took twice as long to develop an application feature, and we mandated near perfect code coverage. Was this approach more successful than my first example? Not really. Sure, we had more confidence in making changes to the code base and having an "immediate view" of the regression impact of the change. But the business paid a price for all of that - a very heavy price. One would think, that given the money it cost for development to test the application the number of defects would be significantly reduced; but they weren't. We had lots of functional and non-functional defects detected by testing which were effectively misinterpretations of business requirements or some gap in the business logic.
Which one, from a business perspective, was more successful? Both. The corollary is that a heavily tested application cost lots of money and takes longer to build. l have seen this first hand. So, time to answer the titan question from my own experiences.
As a developer, you need to test the components that you write; there's no arguing that. Otherwise, how else can you prove the functionality of your components? But, just how far should we push the envelope?
My view is simple. We all need to be pragmatic about how we approach our unit testing. We should always stop and ask ourselves "are we going to far with our unit testing?" As a developer, we are faced with this question constantly. We should always do the most to prove our components are functionally correct, but also write the least amount of unit test code to ensure our testing solution remains simple yet effective. After all, a good developer is a lazy one.
Until next time,
Oscar Huseyin
http://www.odecee.com.au/blogs/ | | |
| | |
| | | most clicked this week from dzone.com |
Most-clicked links this week |
| |
|
| |
| |
|
A recap of
some of the most popular and active Javalobby.org
discussions this week. |
|
Do You Want BGGA Closures? Read this.
|
Closures are powerful, no question about it. Especially so with Neal Gafter's BGGA proposal. Joshua Bloch, creator of the much praised Effective Java, picks them apart in these informative ppt sides.
| |
Full Discussion |
Posted By: Mikael Grev - (148 Replies)
|
|
Named arguments for method calls
|
Picking the right arguments in the right order for a method call can be confusing, prone to mistakes, and sometimes cause ambiguity problems. Naming them in the call could improve this.
| |
Full Discussion |
Posted By: Mike P - (66 Replies)
|
|
True problem with Applets
|
We hear many complaints about Applets, like the fact we must download Java. to me this is not a real issue at all.
A real issue is the fact that with a browser we can't support many versions of Java.
| |
Full Discussion |
Posted By: Serge Bureau - (34 Replies)
|
|
THIS Would Excite Me
|
What gets you excited? Yeah, you can get that all over the web just by Googling... But THIS would excite me, and it can only be delivered by the JDK.
| |
Full Discussion |
Posted By: Mikael Grev - (34 Replies)
|
|
Has O'Reilly given up on Java?
|
Like many IT enthusiasts and/or professionals, I am a big fan of O'Reilly books. However, this publisher doesn't seem to be over-excited with Java.
| |
Full Discussion |
Posted By: Hadrien Flipouk - (20 Replies)
|
| |
| | |
Enterprise Ajax Security for Java EE
|
Can enterprise application developers deliver Rich Internet Applications using Ajax techniques, but do so in a secure and cost-effective manner? This paper examines some of the fundamental security issues related to client-centric Ajax techniques, and will show how these issues can be overcome using a server-centric approach based on Java EE and ICEfaces.
| |
Download Full White Paper |
Posted by: Icesoft
|
| Product and
service announcements for Java developers. |
|
Apache Ivy 2.0 beta 1
|
The Apache Ivy project, tool for managing (recording, tracking, resolving and reporting) project dependencies, is please to announce its 2.0.0 beta 1 release, a new step on the road toward 2.0 final.
| |
Full Announcement & Discussion |
Posted By: Xavier Hanin - (0 Replies)
|
|
JAME 6.0 RC3
|
JAME 6.0 RC3 has been released! JAME is a Java real-time multi-thread fractal platform which supports images and animations.
| |
Full Announcement & Discussion |
Posted By: Andrea Medeghini - (0 Replies)
|
|
soapUI 2.0 Final
|
soapUI 2.0 final has been released with a large number of new features, including WS-Security, SOAP-Monitoring, etc. Huge Thanks to everyone for helping out with testing and reporting!
/eviware.com
| |
Full Announcement & Discussion |
Posted By: Ole Matzura - (0 Replies)
|
| |
|
Back to newsletter list
Rapid Development Environment for Web 2.0
Perspective
