|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 4
With these thoughts in mind, this month I'd like to look at testing in general and Java platform-related testing in particular. Next month, I'll begin to build a framework for testing your Java code.
Let me begin by presenting the overall picture into which testing falls. Most software applications are complex and abstract. The requirements that guide their implementation are often unclear and even contradictory. Consequently, building applications that do what they are supposed to do -- and that continue to do so as changes are made -- is not as easy as it might seem from the outside. In addition, human architects, designers, and developers often make mistakes. In either case, the results are defects.
By testing an application, we hope to uncover the defects that arise from these sources and many others. These defects include typographical errors, logic errors, errors introduced due to insufficient understanding of the problem domain, and errors introduced due to poor programming practice. The process of uncovering these defects is made more difficult due to the nature of the software defects themselves: they don't occur where you expect to find them. Indeed, the likelihood of a defect existing in a particular piece of code is inversely proportional to the probability that a program path through that code will be executed.
Consequently, someone who is testing a program for defects must have a different mindset than someone putting it through everyday use. Remember this: when we test, we execute the functions of an application with the intent of exposing defects. A good test is one that is likely to uncover a flaw that was previously unknown.
Before we go any further, it's worth pointing out the features inherent in the Java language and Java platform that improve our chances of building quality software. Most of these features remove entire classes of defects from consideration.
Since Java compiles applications before they run, checking for errors as it does so, the compiler catches most typographical errors before they can cause runtime errors -- a major improvement over interpreted languages. Similarly, static type checking catches invalid assignments and method parameters during compilation rather than during program execution.
Additionally, if you've migrated to the Java programming language from a language like C++, one of the first differences you probably noticed was all of the details you no longer had to think about while developing applications. You can thankfully forget about object deletion (which, if missed, would eventually lead to your application running out of memory) and a whole host of errors relating to pointer arithmetic and array bounds (both of which can lead to hard-to-find memory-corruption problems).
Java is not magic, however. Even though Java goes a long way toward bullet-proofing your applications, there is still room for defects to creep into the finished product. These defects tend to arise for one of the following reasons: