Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

Sponsored Links

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

Test for fun and profit, Part 2: Unit testing

Learn the ins and outs of testing in a Java environment

By Todd Sundsted, JavaWorld.com, 07/26/01

Page 3 of 3

State

When we perform a test on a unit, we apply a set of inputs and observe what happens at the outputs.

Consider once again the single-class code. When one of the class's methods is invoked, several things happen. First, the method takes the input parameters (node), combines them with the state variables (_hashmap), and produces a result. Second, the state of the object changes (that is, _hashmap holds one more node). For any particular method call both of those things may occur, or only one.

I mentioned earlier that it is often convenient to extend the list of what we observe to include the unit's internal state. That is the case for two reasons:

1. The internal states of some units aren't well reflected in the values of the outputs. In theory, you can make a determination of the unit's internal state, given a large enough input set. However, by opening the box and observing the state of the unit, you can often dramatically reduce the size of the required test set.
   
   
2. Testing is (or should be) the first step in a larger defect-fixing process. That process can be facilitated if the tests provide information about where an error was introduced.

Design for testability

As I stated in the introduction, testing can't be effectively done if it's an afterthought. It deserves as much thought and preparation as the coding itself.

One key component of a testing strategy, therefore, is a methodology and framework that supports the testing process. We'll look at one such framework next month.

Designing for testability represents another important component. Simply stated, designing for testability takes into account a central fact: the design of the units to be tested has a great impact on the ease of testing those units. Therefore, I want to emphasize the importance not just of testing but also of designing applications and their components with testing in mind.

In practice, this boils down to following a few simple rules, some of which you're already probably familiar with:

1. Design nice, clean, well-documented interfaces between components
   
   
2. Observe the rules of encapsulation
   
   
3. Break complex operations into small, easy-to-manage (and easy-to-test) steps

Conclusion

If you've stayed with me this long, I hope you've come to better understand both the importance of testing and the importance of doing it thoroughly. Remember, to test how a unit behaves, you must both identify and control all of its inputs and identify and observe all of its outputs.

Next month we'll begin work on a simple testing framework that will allow you to test your code.

About the author

Read more about Tools & Methods in JavaWorld's Tools & Methods section.