Datasheet

11
Chapter 1: Preliminary Concerns
Have a happy client.  A common measure of success is a happy client. Most clients are very
happy when you spend the time with them to make sure you are developing the system they
want, not the system you or a manager/developer want. Getting the customer involved early
on in the testing is key. Customers should be involved in acceptance testing and can also be
leveraged in running manual test plans.
Where to Start
Getting the terminology down is the first hurdle. In the following chapters we will discuss the termi-
nology and different types of testing disciplines. Where applicable, templates will be provided to help
get you started. The best way to start testing is to jump in headfirst. Pick a project you’re familiar with
and create some tests.
Generally, most companies use a common library or framework for various projects. These frameworks
take the form of logging, data access, message handling, and so on. A good way to learn how to write good
unit tests is to start unit testing this library. You may see that the library you thought had a good architec-
ture is not as easy to test as you expected. Nowadays, most of these frameworks also include their own unit
tests that you can use as reference material. Another great way to start is by looking at other peoples’ tests
with open source projects being a goldmine of useful information. By seeing how other people created tests
for these projects, you will be able to pick up some tricks to help you when you start writing tests.
Getting Started with Test Driven Development
Before you dive into TDD, you should spend a great deal of time working with code that was not designed
to be tested via automation. Focus on techniques and patterns to write good tests for the code you are able
to test. Slowly start to refactor code that is not testable into new abstractions that are testable. Spend time
learning how to break dependencies. When you have hit the point where you understand how to abstract
code out to make it testable, you will then see that Test Driven Development is a horrible name for the
development and it should be named something such as Well Designed Code That Can Be Tested Driven
Development (WDCTCBTDD).
Test Driven Development will be covered in more depth in Chapter 2, but readers should understand it’s
very difficult to decide they are going to practice TDD when they don’t have the fundamental testing and
software design skills in place.
A study commissioned in 2002 by the U.S. Department of Commerce’s National Institute of Standards
and Technology, found software bugs, or errors, are so prevalent and so detrimental that they cost the
U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product.
When Should Testing Be Automated?
The discussion about whether and when testing should be automated has been going back and forth for
many years. When considering this argument, it is important to remember that testing actually covers a
number of different techniques, and as such, this question cannot result in a simple yes or no answer.
Instead, you need to look at every feature and type of testing which needs to be performed and decide
on a case-by-case basis. But how do you decide?
96640c01.indd 11 9/25/09 7:18:28 AM