Stubbing For Fun, Profit, and Survival, Page 2
"Foo" Is Only Missing an "L"
The preceding example returns a meaningful value. Even in the case where full JavaDoc comments are omitted, any developer seeing "John Doe" returned has a pretty good idea how they can use the method. A return value of "foo" would give no such indication. Even if the method has full JavaDoc notations, the value "foo" is very unlikely to be of use to the client code. It may be helpful to consider that code examples that use "foo" generally use "bar" as the second value. "foo bar" is a homonym for FUBAR, which is an acronym for "F***** Up Beyond All Recovery".
I recently worked on a project where stubs returned both null and "foo." These values, coupled with generated JavaDoc comments rather than informative descriptions, led to delays in integration testing and the need to re-write 70% of the consumer code once integration began due to the assumed values not matching the actual values. A valid value returned by stubs for all methods would have prevented this and saved a substantial amount money (and one of my weekends).
Meaningful Stubs May End Up In Production
Some people believe that cleaning up stubbed code takes too much of their time, or that stubs can make their way into production by being missed. Looking at that second argument, it is only valid if comments are not used properly. All modern IDEs will provide a listing of comments that start with FIXME and TODO. Stubs that are commented with FIXME and cultivating the habit of reviewing these lists will always prevent stubs from making it to production and lead to cleaner code. Using these notations also allows for being able to quickly review code where stubs have been left and remove them when they are no longer needed.
Figure 1: Task View in Eclipse
Using a Stub Harness
If you don't know how long it will be until you have data, consider writing a stub harness. A stub harness is a simple check to see if the class should use stubbed values before returning them. Whether to use the stubs or not can be set in a property file at a class or as a node in your deployment descriptor. This value can be set at a method level:
at the application level:
if(property.useStubs && property.thisMethod.useStubs)
The key to this approach is to make sure your build process will never allow these values to be set in either pre-production or production (or other applicable environments, depending on how your organization operates). Providing your processes include regression tests in pre-prod, methods that are still stubbed will fail prior to going to production. It also allows you to switch off the stubs at any stage of development to run integration tests.
There are two inspirations for my article topics. Things that are cool, and things that are painful. In both cases, my goal is to share the solution in the hopes of saving others the long, tedious discovery process that I and others have gone through. In the case of this particular topic, the tedious process isn't the discovery but the realization that an approach that may seem at first glance to be time consuming is in fact time saving.
About the Author
Scott Nelson is a Senior Principal Web Application Consultant with well over 10 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations and real estate agencies for use by employees, customers, vendors, franchisees, executive management and others who use a browser. For information on how he can help with your web applications, please visit http://www.fywservices.com/ He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.