<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="-nwZMQTZtIwI5weh9c_HoYA" name="test_ideas_for_method_calls,8.5657170364036E-306" guid="-nwZMQTZtIwI5weh9c_HoYA" changeDate="2006-11-21T15:58:59.045-0800" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_test__developer_testing__test_ideas__for_method_calls&quot;
name=&quot;XE_test__developer_testing__test_ideas__for_method_calls&quot;&gt;&lt;/a&gt;&lt;a
id=&quot;XE_design__developer_testing__test_ideas__for_method_calls&quot;
name=&quot;XE_design__developer_testing__test_ideas__for_method_calls&quot;&gt;&lt;/a&gt;&lt;a id=&quot;XE_test-ideas__for_method_calls&quot;
name=&quot;XE_test-ideas__for_method_calls&quot;&gt;&lt;/a&gt; 
&lt;h3&gt;
    &lt;a id=&quot;Introduction&quot; name=&quot;Introduction&quot;&gt;Introduction&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    Here's an example of defective code:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
File file = new File(stringName);
file.delete();
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    The defect is that &lt;font size=&quot;+0&quot;&gt;File.delete&lt;/font&gt; can fail, but the code doesn't check for that. Fixing it requires
    the addition of the italicized code shown here:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
File file = new File(stringName);
&lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;if (&lt;/b&gt;&lt;/i&gt;&lt;/font&gt;file.delete()&lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;== false) {...}&lt;/b&gt;&lt;/i&gt;&lt;/font&gt;
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    This guideline describes a method for detecting cases where your code does not handle the result of calling a method.
    (Note that it assumes that the method called produces the correct result for whatever inputs you give it. That's
    something that should be tested, but creating test ideas for the called method is a separate activity. That is, it's
    not your job to test &lt;font size=&quot;+0&quot;&gt;File.delete&lt;/font&gt;.)
&lt;/p&gt;
&lt;p&gt;
    The key notion is that you should create a test idea for each &lt;i&gt;distinct unhandled relevant result&lt;/i&gt; of a method
    call. To define that term, let's first look at &lt;i&gt;result&lt;/i&gt;. When a method executes, it changes the state of the
    world. Here are some examples:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        It might push return values on the runtime stack.
    &lt;/li&gt;
    &lt;li&gt;
        It might throw an exception.
    &lt;/li&gt;
    &lt;li&gt;
        It might change a global variable.
    &lt;/li&gt;
    &lt;li&gt;
        It might update a record in a database.
    &lt;/li&gt;
    &lt;li&gt;
        It might send data over the network.
    &lt;/li&gt;
    &lt;li&gt;
        It might print a message to standard output.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    Now let's look at &lt;i&gt;relevant&lt;/i&gt;, again using some examples.
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Suppose the method being called prints a message to standard output. That &quot;changes the state of the world&quot;, but it
        cannot affect the further processing of this program. No matter what gets printed, even nothing at all, it can't
        affect the execution of your code.
    &lt;/li&gt;
    &lt;li&gt;
        If the method returns true for success and false for failure, your program very likely should branch based on the
        result. So that return value is relevant.
    &lt;/li&gt;
    &lt;li&gt;
        If the called method updates a database record that your code later reads and uses, the result (updating the
        record) is relevant.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    (There's no absolute line between relevant and irrelevant. By calling &lt;font size=&quot;+0&quot;&gt;print&lt;/font&gt;, your method might
    cause buffers to be allocated, and that allocation might be relevant after &lt;font size=&quot;+0&quot;&gt;print&lt;/font&gt; returns. It's
    conceivable that a defect might depend on whether and what buffers were allocated. It's conceivable, but is it at all
    plausible?)
&lt;/p&gt;
&lt;p&gt;
    A method might often have a very large number of results, but only some of them will be &lt;i&gt;distinct&lt;/i&gt;. For example,
    consider a method that writes bytes to disk. It might return a number less than zero to indicate failure; otherwise, it
    returns the number of bytes written (which might be fewer than the number requested). The large number of possibilities
    can be grouped into three distinct results:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        a number less than zero.
    &lt;/li&gt;
    &lt;li&gt;
        the number written equals the number requested
    &lt;/li&gt;
    &lt;li&gt;
        some bytes were written, but less than the number requested.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    All the values less than zero are grouped into one result because no reasonable program will make a distinction among
    them. All of them (if, indeed, more than one is possible) should be treated as an error. Similarly, if the code
    requested that 500 bytes be written, it doesn't matter if 34 were actually written or 340: the same thing will probably
    be done with the unwritten bytes. (If something different should be done for some value, such as 0, that will form a
    new distinct result.)
&lt;/p&gt;
&lt;p&gt;
    There's one last word in the defining term to explain. This particular testing technique is not concerned with distinct
    results that are already &lt;i&gt;handled&lt;/i&gt;. Consider, again, this code:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
File file = new File(stringName);
if (file.delete() == false) {...}
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    There are two distinct results (true and false). The code handles them. It might handle them incorrectly, but test
    ideas from &lt;a class=&quot;elementLinkWithType&quot;
    href=&quot;./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html&quot;
    guid=&quot;1.7150344523489172E-305&quot;&gt;Guideline: Test Ideas for Booleans and Boundaries&lt;/a&gt; will check that. This test
    technique is concerned with distinct results that are not specifically handled by distinct code. That might happen for
    two reasons: you thought the distinction was irrelevant, or you simply overlooked it. Here's an example of the first
    case:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
result = m.method();
switch (result) {
    case FAIL:
    case CRASH:
       ...
       break;
    case DEFER:
       ...
       break;
    default:
       ...
       break;
}
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    &lt;font size=&quot;+0&quot;&gt;FAIL&lt;/font&gt; and &lt;font size=&quot;+0&quot;&gt;CRASH&lt;/font&gt; are handled by the same code. It might be wise to check
    that that's really appropriate. Here's an example of an overlooked distinction:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
result = s.shutdown();
if (result == PANIC) {
   ...
} else {
   // success! Shut down the reactor.
   ...
} 
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    It turns out that shutdown can return an additional distinct result: &lt;font size=&quot;+0&quot;&gt;RETRY&lt;/font&gt;. The code as written
    treats that case the same as the success case, which is almost certainly wrong.
&lt;/p&gt;
&lt;h3&gt;
    &lt;a id=&quot;FindingTestIdeas&quot; name=&quot;FindingTestIdeas&quot;&gt;Finding test ideas&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    So your goal is to think of those distinct relevant results you previously overlooked. That seems impossible: why would
    you realize they're relevant now if you didn't earlier?
&lt;/p&gt;
&lt;p&gt;
    The answer is that a systematic re-examination of your code, when in a testing frame of mind and not a programming
    frame of mind, can sometimes cause you to think new thoughts. You &lt;i&gt;can&lt;/i&gt; question your own assumptions by
    methodically stepping through your code, looking at the methods you call, rechecking their documentation, and thinking.
    Here are some cases to watch for.
&lt;/p&gt;
&lt;h4&gt;
    &quot;Impossible&quot; cases
&lt;/h4&gt;
&lt;p&gt;
    Often, it will appear that error returns are impossible. Doublecheck your assumptions.
&lt;/p&gt;
&lt;p&gt;
    This example shows a Java implementation of a common Unix idiom for handling temporary files.
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
File file = new File(&quot;tempfile&quot;);
FileOutputStream s;
try {
    // open the temp file.
    s = new FileOutputStream(file);
} catch (IOException e) {...}
// Make sure temp file will be deleted
file.delete();
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    The goal is to make sure that a temporary file is always deleted, no matter how the program exits. You do this by
    creating the temporary file, then immediately deleting it. On Unix, you can continue to work with the deleted file, and
    the operating system takes care of cleaning up when the process exits. A not-painstaking Unix programmer might not
    write the code to check for a failed deletion. Since she just successfully created the file, she must be able to delete
    it.
&lt;/p&gt;
&lt;p&gt;
    This trick doesn't work on Windows. The deletion will fail because the file is open. Discovering that fact is hard: as
    of August 2000, the Java documentation did not enumerate the situations in which &lt;font size=&quot;+0&quot;&gt;delete&lt;/font&gt; could
    fail; it merely says that it can. But-perhaps-when in &quot;testing mode&quot;, the programmer might question her assumption.
    Since her code is supposed to be &quot;write once, run everywhere&quot;, she might ask a Windows programmer when &lt;font
    size=&quot;+0&quot;&gt;File.delete&lt;/font&gt; fails on Windows and so discover the awful truth.
&lt;/p&gt;
&lt;h4&gt;
    &quot;Irrelevant&quot; cases
&lt;/h4&gt;
&lt;p&gt;
    Another force against noticing a distinct relevant value is being already convinced that it doesn't matter. A Java
    &lt;font size=&quot;+0&quot;&gt;Comparator&lt;/font&gt;'s &lt;font size=&quot;+0&quot;&gt;compare&lt;/font&gt; method returns either a number &amp;lt;0, 0, or a number
    &amp;gt;0. Those are three distinct cases that might be tried. This code lumps two of them together:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
void allCheck(Comparator c) {
   ...
   if (c.compare(o1, o2) &amp;lt;= 0) {
      ...
   } else {
      ...
   } 
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    But that might be wrong. The way to discover whether it is or not is to try the two cases separately, even if you
    really believe it will make no difference. (Your beliefs are really what you're testing.) Note that you might be
    executing the &lt;font size=&quot;+0&quot;&gt;then&lt;/font&gt; case of the &lt;font size=&quot;+0&quot;&gt;if&lt;/font&gt; statement more than once for other
    reasons. Why not try one of them with the result less than 0 and one with the result exactly equal to zero?
&lt;/p&gt;
&lt;h4&gt;
    Uncaught exceptions
&lt;/h4&gt;
&lt;p&gt;
    Exceptions are a kind of distinct result. By way of background, consider this code:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
void process(Reader r) {
   ...
   try {
      ...
      int c = r.read();
      ...
   } catch (IOException e) {
      ...
   }
}
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    You'd expect to check whether the handler code really does the right thing with a read failure. But suppose an
    exception is explicitly unhandled. Instead, it's allowed to propagate upward through the code under test. In Java, that
    might look like this:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
void process(Reader r) &lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;throws IOException&lt;/b&gt;&lt;/i&gt;&lt;/font&gt; {
    ...
    int c = r.read();
    ...
}
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    This technique asks you to test that case &lt;i&gt;even though&lt;/i&gt; the code explicitly doesn't handle it. Why? Because of
    this kind of fault:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
void process(Reader r) throws IOException {
    ...
    &lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;Tracker.hold(this);&lt;/b&gt;&lt;/i&gt;&lt;/font&gt;
    ...
    int c = r.read();
    ...
    &lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;Tracker.release(this);&lt;/b&gt;&lt;/i&gt;&lt;/font&gt;
    ...
}
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    Here, the code affects global state (through &lt;font size=&quot;+0&quot;&gt;Tracker.hold&lt;/font&gt;). If the exception is thrown, &lt;font
    size=&quot;+0&quot;&gt;Tracker.release&lt;/font&gt; will never be called.
&lt;/p&gt;
&lt;p&gt;
    (Notice that the failure to release will probably have no obvious immediate consequences. The problem will most likely
    not be visible until &lt;font size=&quot;+0&quot;&gt;process&lt;/font&gt; is called again, whereupon the attempt to &lt;font
    size=&quot;+0&quot;&gt;hold&lt;/font&gt; the object for a second time will fail. A good article about such defects is Keith Stobie's &lt;a
    href=&quot;http://www.testingcraft.com/stobie-exceptions.pdf&quot; target=&quot;_blank&quot;&gt;&quot;Testing for Exceptions&quot;&lt;/a&gt;. &amp;nbsp; (&lt;a
    href=&quot;http://www.adobe.com/products/acrobat/alternate.html&quot; target=&quot;_blank&quot;&gt;Get Adobe Reader&lt;/a&gt;))
&lt;/p&gt;
&lt;h3&gt;
    &lt;a id=&quot;UndiscoveredFaults&quot; name=&quot;UndiscoveredFaults&quot;&gt;Undiscovered faults&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    This particular technique does not address all defects associated with method calls. Here are two kinds that it's
    unlikely to catch.
&lt;/p&gt;
&lt;h4&gt;
    Incorrect arguments
&lt;/h4&gt;
&lt;p&gt;
    Consider these two lines of C code, where the first line is wrong and the second line is correct.
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
... strncmp(s1, s2, strlen(s1)) ...
... strncmp(s1, s2, strlen(&lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;s2&lt;/b&gt;&lt;/i&gt;&lt;/font&gt;)) ...
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    &lt;font size=&quot;+0&quot;&gt;strncmp&lt;/font&gt; compares two strings and returns a number less than 0 if the first one is
    lexicographically less than the second (would come earlier in a dictionary), 0 if they're equal, and a number greater
    than 0 if the first one is lexicographically larger. However, it only compares the number of characters given by the
    third argument. The problem is that the length of the first string is used to limit the comparison, whereas it should
    be the length of the second.
&lt;/p&gt;
&lt;p&gt;
    This technique would require three tests, one for each distinct return value. Here are three you could use:
&lt;/p&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;table
    style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;
     cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;85%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;&gt;
        &lt;tbody&gt;
            &lt;tr&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    s1
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    s2
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    expected result
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    actual result
                &lt;/th&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;a&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;bbb&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &amp;lt;0
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &amp;lt;0
                &lt;/td&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;bbb&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;a&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &amp;gt;0
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &amp;gt;0
                &lt;/td&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;foo&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;foo&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    =0
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    =0
                &lt;/td&gt;
            &lt;/tr&gt;
        &lt;/tbody&gt;
    &lt;/table&gt;
    &lt;br /&gt;
&lt;/div&gt;
&lt;p&gt;
    The defect is not discovered because nothing in this technique &lt;i&gt;forces&lt;/i&gt; the third argument to have any particular
    value. What's needed is a test case like this:
&lt;/p&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;table
    style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;
     cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;85%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;&gt;
        &lt;tbody&gt;
            &lt;tr&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    &lt;b&gt;s1&lt;/b&gt; 
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    &lt;b&gt;s2&lt;/b&gt; 
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    &lt;b&gt;expected result&lt;/b&gt; 
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    &lt;b&gt;actual result&lt;/b&gt; 
                &lt;/th&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;foo&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &quot;foo&lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;d&lt;/b&gt;&lt;/i&gt;&lt;/font&gt;&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &lt;font color=&quot;#ff0000&quot;&gt;&lt;i&gt;&lt;b&gt;&amp;lt;0&lt;/b&gt;&lt;/i&gt;&lt;/font&gt; 
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    =0
                &lt;/td&gt;
            &lt;/tr&gt;
        &lt;/tbody&gt;
    &lt;/table&gt;
    &lt;br /&gt;
&lt;/div&gt;
&lt;p&gt;
    While there are techniques suitable for catching such defects, they are seldom used in practice. Your testing effort is
    probably better spent on a rich set of tests that targets many types of defects (and that you hope catches this type as
    a side effect).
&lt;/p&gt;
&lt;h4&gt;
    Indistinct results
&lt;/h4&gt;
&lt;p&gt;
    There's a danger that comes when you're coding - and testing - method-by-method. Here's an example. There are two
    methods. The first, &lt;font size=&quot;+0&quot;&gt;connect&lt;/font&gt;, wants to establish a network connection:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
void connect() {
   ...
   Integer portNumber = serverPortFromUser();
   if (portNumber == null) {
      // pop up message about invalid port number
      return;
   }
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    It calls &lt;font size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt; to get a port number. That method returns two distinct values. It
    returns a port number chosen by the user if the number chosen is valid (1000 or greater). Otherwise, it returns null.
    If null is returned, the code under test pops up an error message and quits.
&lt;/p&gt;
&lt;p&gt;
    When &lt;font size=&quot;+0&quot;&gt;connect&lt;/font&gt; was tested, it worked as intended: a valid port number caused a connection to be
    established, and an invalid one led to a popup.
&lt;/p&gt;
&lt;p&gt;
    The code to &lt;font size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt; is a bit more complicated. It first pops up a window that asks
    for a string and has the standard OK and CANCEL buttons. Based on what the user does, there are four cases:
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        If the user types a valid number, that number is returned.
    &lt;/li&gt;
    &lt;li&gt;
        If the number is too small (less than 1000), null is returned (so the message about invalid port number will be
        displayed).
    &lt;/li&gt;
    &lt;li&gt;
        If the number is misformatted, null is again returned (and the same message is appropriate).
    &lt;/li&gt;
    &lt;li&gt;
        If the user clicks CANCEL, null is returned.
    &lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;
    This code also works as intended.
&lt;/p&gt;
&lt;p&gt;
    The combination of the two chunks of code, though, has a bad consequence: the user presses CANCEL and gets a message
    about an invalid port number. All the code works as intended, but the overall effect is still wrong. It was tested in a
    reasonable way, but a defect was missed.
&lt;/p&gt;
&lt;p&gt;
    The problem here is that &lt;font size=&quot;+0&quot;&gt;null&lt;/font&gt; is one result that represents two distinct &lt;i&gt;meanings&lt;/i&gt; (&quot;bad
    value&quot; and &quot;user cancelled&quot;). Nothing in this technique forces you to notice that problem with the design of &lt;font
    size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt;.
&lt;/p&gt;
&lt;p&gt;
    Testing can help, though. When &lt;font size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt; is tested in isolation - just to see if it
    returns the intended value in each of those four cases - the context of use is lost. Instead, suppose it were tested
    via &lt;font size=&quot;+0&quot;&gt;connect&lt;/font&gt;. There would be four tests that would exercise both of the methods simultaneously:
&lt;/p&gt;
&lt;div align=&quot;center&quot;&gt;
    &lt;table
    style=&quot;BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid&quot;
     cellspacing=&quot;0&quot; bordercolordark=&quot;#808080&quot; cellpadding=&quot;4&quot; width=&quot;85%&quot; bordercolorlight=&quot;#808080&quot; border=&quot;1&quot;&gt;
        &lt;tbody&gt;
            &lt;tr&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    input
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    expected result
                &lt;/th&gt;
                &lt;th scope=&quot;col&quot; align=&quot;middle&quot; width=&quot;25%&quot; bgcolor=&quot;#c0c0c0&quot;&gt;
                    thought process
                &lt;/th&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    user types &quot;1000&quot;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    connection to port 1000 is opened
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &lt;font size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt; returns a number, which is used.
                &lt;/td&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td&gt;
                    &lt;p align=&quot;center&quot;&gt;
                        user types &quot;999&quot;
                    &lt;/p&gt;
                &lt;/td&gt;
                &lt;td&gt;
                    &lt;p align=&quot;center&quot;&gt;
                        popup about invalid port number
                    &lt;/p&gt;
                &lt;/td&gt;
                &lt;td&gt;
                    &lt;p align=&quot;center&quot;&gt;
                        &lt;font size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt; returns null, which leads to popup
                    &lt;/p&gt;
                &lt;/td&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &lt;p align=&quot;center&quot;&gt;
                        user types &quot;i99&quot;
                    &lt;/p&gt;
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    popup about invalid port number
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &lt;font size=&quot;+0&quot;&gt;serverPortFromUser&lt;/font&gt; returns null, which leads to popup
                &lt;/td&gt;
            &lt;/tr&gt;
            &lt;tr&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    users clicks CANCEL
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    whole connection process should be cancelled
                &lt;/td&gt;
                &lt;td align=&quot;middle&quot; width=&quot;25%&quot;&gt;
                    &lt;font size=&quot;+0&quot;&gt;&lt;i&gt;serverPortFromUser&lt;/i&gt;&lt;/font&gt; &lt;i&gt;returns null, hey wait a minute that doesn't make
                    sense...&lt;/i&gt; 
                &lt;/td&gt;
            &lt;/tr&gt;
        &lt;/tbody&gt;
    &lt;/table&gt;
    &lt;br /&gt;
&lt;/div&gt;
&lt;p&gt;
    As is often the case, testing in a larger context reveals integration problems that escape small-scale testing. And, as
    is also often the case, careful thought during test design reveals the problem before the test is run. (But if the
    defect isn't caught then, it will be caught when the test is run.)&lt;br /&gt;
    &lt;br /&gt;
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>