2 Why We Need Model-Based Testing

Overview 29
That 0.0 sample right after 100.0 looks suspicious. Perhaps there is a poor connection
at the sensor? But a few minutes later we see:
2006-11-07 16:10:21Z Temperature server at port 8023 reports 99.8 F
2006-11-07 16:10:31Z Temperature server at port 8023 reports 99.9 F
2006-11-07 16:10:41Z Temperature server at port 8023 reports 100.0 F
2006-11-07 16:10:51Z Temperature server at port 8023 reports 99.0 F
2006-11-07 16:11:01Z Temperature server at port 8023 reports 999.0 F
2006-11-07 16:11:11Z Temperature server at port 8023 reports 899.0 F
That doesn’t look like a bad connection. Investigating at the embedded computer
confirms that the sensor and server program are working correctly.
It seems significant that troubles appear after the temperature reaches 100. But
our unit test for 212 passed. What could be wrong?
2.10 Failures explained
After some investigation we discover the defect: the incorrect code that caused the
failures. 3 The client’s receive buffer is only four bytes long (BUFLEN in the Client
class, Figure 2.5). We intended 40, not 4: a typographical error that was not caught by
the compiler, by inspection, or by unit testing. When the server sends more than four
characters, for example, 100.0, the client only reads the first four, 100. here, and then
finds the remaining character(s) in the buffer the next time it calls Receive. In this
way, a single sample can cause the client to become unsynchronized with the server,
resulting in incorrect readings on one or more subsequent samples. 4 The unit test of
Section 2.8 passed because the client Receive method uses Double.Parse to convert
the buffer contents to a floating point number. This returns the same result when
trailing zeroes are omitted, so the assertion did not detect that the final character was
missing from the sample. This test only acquired one sample; subsequent samples
that would have caused the assertion to fail were not requested.
You might object that this example is naive and unrealistic. In fact, it is a simplified
account of a real experience that was too complicated to describe here in full detail.
2.11 Lessons learned
Some defects can only be revealed by realistic scenarios that resemble actual application
program runs (as in Section 2.9), where we execute long sequences of
3 We distinguish defects (flaws in the code) from failures (occurrences where the program does
the wrong thing). Both are sometimes called bugs.
4 You can observe this by instrumenting Server.Send and Client.Receive with code that
shows the contents of sendBuf and receiveBuf, respectively.
more free ebooks download links at:
http://www.ebook-x.com