Addison.Wesley
By : Gerard Meszaros
Preface
In Chapter 4 of Refactoring [Ref], Martin Fowler writes:
If you look at how most programmers spend their time, you’ll fi nd that writing code is actually a small fraction. Some time is spent fi guring out what ought to be going on, some time is spent designing, but most time is spent debugging. I’m sure every reader can remember long hours of debugging, often long into the night. Every programmer can tell a story of a bug that took a whole day (or more) to fi nd. Fixing the bug is usually pretty quick, but fi nding it is a nightmare. And then when you do fi x a bug, there’s always a chance that anther one will appear and that you might not even notice it until much later.
Then you spend ages fi nding that bug. Some software is very diffi cult to test manually. In these cases, we are often forced into writing test programs.
I recall a project I was working on in 1996. My task was to build an event framework that would let client software register for an event and be notified when some other software raised that event (the Observer [GOF] pattern). I could not think of a way to test this framework without writing some sample client software. I had about 20 different scenarios I needed to test, so I coded up each scenario with the requisite number of observers, events, and event raisers. At first, I logged what was occurring in the console and scanned it manually. This scanning became very tedious very quickly.
Being quite lazy, I naturally looked for an easier way to perform this testing. For each test I populated a Dictionary indexed by the expected event and the expected receiver of it with the name of the receiver as the value. When a particular receiver was notifi ed of the event, it looked in the Dictionary for the entry indexed by itself and the event it had just received. If this entry existed, the receiver removed the entry. If it didn’t, the receiver added the entry with an error message saying it was an unexpected event notifi cation.
After running all the tests, the test program merely looked in the Dictionary and printed out its contents if it was not empty. As a result, running all of my tests had a nearly zero cost. The tests either passed quietly or spewed a list of test failures. I had unwittingly discovered the concept of a Mock Object (page 544) and a Test Automation Framework (page 298) out of necessity!
If you look at how most programmers spend their time, you’ll fi nd that writing code is actually a small fraction. Some time is spent fi guring out what ought to be going on, some time is spent designing, but most time is spent debugging. I’m sure every reader can remember long hours of debugging, often long into the night. Every programmer can tell a story of a bug that took a whole day (or more) to fi nd. Fixing the bug is usually pretty quick, but fi nding it is a nightmare. And then when you do fi x a bug, there’s always a chance that anther one will appear and that you might not even notice it until much later.
Then you spend ages fi nding that bug. Some software is very diffi cult to test manually. In these cases, we are often forced into writing test programs.
I recall a project I was working on in 1996. My task was to build an event framework that would let client software register for an event and be notified when some other software raised that event (the Observer [GOF] pattern). I could not think of a way to test this framework without writing some sample client software. I had about 20 different scenarios I needed to test, so I coded up each scenario with the requisite number of observers, events, and event raisers. At first, I logged what was occurring in the console and scanned it manually. This scanning became very tedious very quickly.
Being quite lazy, I naturally looked for an easier way to perform this testing. For each test I populated a Dictionary indexed by the expected event and the expected receiver of it with the name of the receiver as the value. When a particular receiver was notifi ed of the event, it looked in the Dictionary for the entry indexed by itself and the event it had just received. If this entry existed, the receiver removed the entry. If it didn’t, the receiver added the entry with an error message saying it was an unexpected event notifi cation.
After running all the tests, the test program merely looked in the Dictionary and printed out its contents if it was not empty. As a result, running all of my tests had a nearly zero cost. The tests either passed quietly or spewed a list of test failures. I had unwittingly discovered the concept of a Mock Object (page 544) and a Test Automation Framework (page 298) out of necessity!
Type Pdf
Size 5.16 MB
Download This book
Label:
Test Patterns
Langganan:
Posting Komentar (Atom)
0 komentar: