<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-wuu2cNRUPlrBuaO0OdzLFg" name=",_ByOd4O6pEduvoopEslG-4g" guid="-wuu2cNRUPlrBuaO0OdzLFg" changeDate="2008-08-14T04:53:04.000-0700" version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Establish expectations&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Those who find developer testing rewarding do it. Those who view it as a chore find ways to avoid it. This is simply in&#xD;
    the nature of most developers in most industries, and treating it as a shameful lack of discipline hasn't historically&#xD;
    been successful. Therefore, as a developer you should expect testing to be rewarding and do what it takes to make it&#xD;
    rewarding.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Ideal developer testing follows a very tight edit-test loop. You make a small change to the product, such as adding a&#xD;
    new method to a class, then you immediately rerun your tests. If any test breaks, you know exactly what code is the&#xD;
    cause. This easy, steady pace of development is the greatest reward of developer testing. A long debugging session&#xD;
    should be exceptional.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Because it's not unusual for a change made in one class to break something in another, you should expect to rerun not&#xD;
    just the changed class's tests, but many tests. Ideally, you rerun the complete test suite for your implementation&#xD;
    element many times per hour. Every time you make a significant change, you rerun the suite, watch the results, and&#xD;
    either proceed to the next change or fix the last change. Expect to spend some effort making that rapid feedback&#xD;
    possible.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Write and maintain&amp;nbsp;tests&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    Automate your tests&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Running tests often is not practical if tests are manual. For some implementation elements, automated tests are easy.&#xD;
    An example would be an in-memory database. It communicates to its clients through an API and has no other interface to&#xD;
    the outside world. Tests for it would look something like this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
/* Check that elements can be added at most once. */&#xD;
// Setup&#xD;
Database db = new Database();&#xD;
db.add(&quot;key1&quot;, &quot;value1&quot;);&#xD;
// Test&#xD;
boolean result = db.add(&quot;key1&quot;, &quot;another value&quot;);&#xD;
expect(result == false);&#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    The tests are different from ordinary client code in only one way: instead of believing the results of API calls, they&#xD;
    check. If the API makes client code easy to write, it makes test code easy to write. If the test code is &lt;i>not&lt;/i>&#xD;
    easy to write, you've received an early warning that the API could be improved. Test-first design is thus consistent&#xD;
    with the iterative processes' focus on addressing important risks early.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The more tightly connected the element is to the outside world, however, the harder it will be to test. There are two&#xD;
    common cases: graphical user interfaces and back-end components.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Graphical user interfaces&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    Suppose the database in the example above receives its data via a callback from a user-interface object. The callback&#xD;
    is invoked when the user fills in some text fields and pushes a button. Testing this by manually filling in the fields&#xD;
    and pushing the button isn't something you want to do many times an hour. You must arrange a way to deliver the input&#xD;
    under programmatic control, typically by &quot;pushing&quot; the button in code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Pushing the button causes some code in the implementation element to be executed. Most likely, that code changes the&#xD;
    state of some user-interface objects. So you must also arrange a way to query those objects programmatically.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Back-end components&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    Suppose the element under test doesn't implement a database. Instead, it's a wrapper around a real, on-disk database.&#xD;
    Testing against that real database might be difficult. It might be hard to install and configure. Licenses for it might&#xD;
    be expensive. The database might slow down the tests enough that you're not inclined to run them often. In such cases,&#xD;
    it's worthwhile to &quot;stub out&quot; the database with a simpler element that does just enough to support the tests.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Stubs are also useful when a component that your element talks to isn't ready yet. You don't want your testing to wait&#xD;
    on someone else's code.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Don't write your own tools&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Developer testing seems pretty straightforward. You set up some objects, make a call through an API, check the result,&#xD;
    and announce a test failure if the results aren't as expected. It's also convenient to have some way to group tests so&#xD;
    that they can be run individually or as complete suites. Tools that support those requirements are called &lt;i>test&#xD;
    frameworks&lt;/i>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Developer testing &lt;b>is&lt;/b> straightforward, and the requirements for test frameworks are not complicated. If, however,&#xD;
    you yield to the temptation of writing your own test framework, you'll spend much more time tinkering with the&#xD;
    framework than you probably expect. There are many test frameworks available, both commercial and open source, and&#xD;
    there's no reason not to use one of those.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Do create support code&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Test code tends to be repetitive. It's common to see sequences of code like this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
// null name not allowed&#xD;
retval = o.createName(&quot;&quot;); &#xD;
expect(retval == null);&#xD;
// leading spaces not allowed&#xD;
retval = o.createName(&quot; l&quot;); &#xD;
expect(retval == null);&#xD;
// trailing spaces not allowed&#xD;
retval = o.createName(&quot;name &quot;); &#xD;
expect(retval == null);&#xD;
// first character may not be numeric&#xD;
retval = o.createName(&quot;5allpha&quot;); &#xD;
expect(retval == null);&#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    This code is created by copying one check, pasting it, then editing it to make another check.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The danger here is twofold. If the interface changes, much editing will have to be done. (In more complicated cases, a&#xD;
    simple global replacement won't suffice.) Also, if the code is at all complicated, the intent of the test can be lost&#xD;
    amid all the text.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When you find yourself repeating yourself, seriously consider factoring out the repetition into support code. Even&#xD;
    though the code above is a simple example, it's more readable and maintainable if written like this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
void expectNameRejected(MyClass o, String s) {&#xD;
Object retval = o.createName(s);&#xD;
expect(retval == null);&#xD;
}&#xD;
...&#xD;
// null name not allowed&#xD;
expectNameRejected(o, &quot;&quot;); &#xD;
// leading spaces not allowed.&#xD;
expectNameRejected(o, &quot; l&quot;); &#xD;
// trailing spaces not allowed.&#xD;
expectNameRejected(o, &quot;name &quot;); &#xD;
// first character may not be numeric.&#xD;
expectNameRejected(o, &quot;5alpha&quot;); &#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    Developers writing tests often err on the side of too much copying-and-pasting. If you suspect yourself of that&#xD;
    tendency, it's useful to consciously err in the other direction. Resolve that you will strip your code of all duplicate&#xD;
    text.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Keep the tests understandable&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    You should expect that you, or someone else, will have to modify the tests later. A typical situation is that a later&#xD;
    iteration calls for a change to the element's behavior. As a simple example, suppose the element once declared a square&#xD;
    root method like this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;+0&quot;>double sqrt(double x);&lt;/font>&#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    In that version, a negative argument caused the function &quot;sqrt&quot; to return NaN (&quot;not a number&quot; from the IEEE 754-1985&#xD;
    &lt;i>Standard for Binary Floating-Point Arithmetic&lt;/i>). In the new iteration, the square root method will accept&#xD;
    negative numbers and return a complex result:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;+0&quot;>Complex sqrt(double x);&lt;/font>&#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    Old tests for the function &quot;sqrt&quot; will have to change. That means understanding what they do, and updating them so that&#xD;
    they work with the new &quot;sqrt&quot;. When updating tests, you must take care not to destroy their bug-finding power. One way&#xD;
    that sometimes happens is this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
void testSQRT () {&#xD;
//  Update these tests for Complex &#xD;
// when I have time -- bem&#xD;
/*&#xD;
double result = sqrt(0.0);&#xD;
...&#xD;
*/&#xD;
}&#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    Other ways are more subtle: the tests are changed so that they actually run, but they no longer test what they were&#xD;
    originally intended to test. The end result, over many iterations, can be a test suite that is too weak to catch many&#xD;
    bugs. This is sometimes called &quot;test suite decay&quot;. A decayed suite will be abandoned, because it's not worth the&#xD;
    upkeep.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Test suite decay is less likely in the direct tests for the function &quot;sqrt&quot; than in indirect tests. There will be code&#xD;
    that calls the function &quot;sqrt&quot;. That code will have tests. When the function &quot;sqrt&quot; changes, some of those tests will&#xD;
    fail. The person who changes the function &quot;sqrt&quot; will probably have to change those tests. Because he's less familiar&#xD;
    with them, and because their relationship to the change is less clear, he's more likely to weaken them in the process&#xD;
    of making them pass.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When you're creating support code for tests (as urged above), be careful: the support code should clarify, not obscure,&#xD;
    the purpose of the tests that use it. A common complaint about object-oriented programs is that there's no one place&#xD;
    where anything's done. If you look at any one method, all you discover is that it forwards its work somewhere else.&#xD;
    Such a structure has advantages, but it makes it harder for new people to understand the code. Unless they make an&#xD;
    effort, their changes are likely to be incorrect or to make the code even more complicated and fragile. The same is&#xD;
    true of test code, except that later maintainers are even less likely to take due care. You must head off the problem&#xD;
    by writing understandable tests.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Match the test structure to the product structure&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Suppose someone has inherited your implementation element. They need to change a part of it. They may want to examine&#xD;
    the old tests to help them in their new design. They want to update the old tests before writing the code (test-first&#xD;
    design).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    All those good intentions will go by the wayside if they can't find the appropriate tests. What they'll do is make the&#xD;
    change, see what tests fail, then fix those. That will contribute to test suite decay.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For that reason, it's important that the test suite be well structured, and that the location of tests be predictable&#xD;
    from the structure of the product. Most usually, developers arrange tests in a parallel hierarchy, with one test class&#xD;
    per product class. So if someone is changing a class named &quot;Log&quot;, they know the test class is &quot;TestLog&quot;, and they know&#xD;
    where the source file can be found.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Let tests violate encapsulation&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    You might limit your tests to interacting with your implementation element exactly as client code does, through the&#xD;
    same interface that client code uses. However, this has disadvantages. Suppose you're testing a simple class that&#xD;
    maintains a doubly linked list:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In particular, you're testing the &quot;DoublyLinkedList.insertBefore(Object existing, Object newObject)&quot; method. In one of&#xD;
    your tests, you want to insert an element in the middle of the list, then check if it's been inserted successfully. The&#xD;
    test uses the list above to create this updated list:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It checks the list correctness like this:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
// the list is now one longer. &#xD;
expect(list.size()==3);&#xD;
// the new element is in the correct position&#xD;
expect(list.get(1)==m);&#xD;
// check that other elements are still there.&#xD;
expect(list.get(0)==a);&#xD;
expect(list.get(2)==z);&#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    That seems sufficient, but it's not. Suppose the list implementation is incorrect and backward pointers are not set&#xD;
    correctly. That is, suppose the updated list actually looks like this:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If the function &quot;DoublyLinkedList.get(int index)&quot; traverses the list from the beginning to the end (likely), the test&#xD;
    would miss this failure. If the class provides &quot;elementBefore&quot; and &quot;elementAfter&quot; methods, checking for such failures&#xD;
    is straightforward:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
// Check that links were all updated&#xD;
expect(list.elementAfter(a)==m);&#xD;
expect(list.elementAfter(m)==z);&#xD;
expect(list.elementBefore(z)==m); //this will fail&#xD;
expect(list.elementBefore(m)==a);&#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    But what if it doesn't provide those methods? You could devise more elaborate sequences of method calls that will fail&#xD;
    if the suspected defect is present. For example, this would work:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
// Check whether back-link from Z is correct.&#xD;
list.insertBefore(z, x);&#xD;
// If it was incorrectly not updated, X will have &#xD;
// been inserted just after A.&#xD;
expect(list.get(1)==m); &#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    But such a test is more work to create and is likely to be significantly harder to maintain. (Unless you write good&#xD;
    comments, it will not be at all clear why the test is doing what it's doing.) There are two solutions:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Add the &quot;elementBefore&quot; and &quot;elementAfter&quot; methods to the public interface. But that effectively exposes the&#xD;
        implementation to everyone and makes future change more difficult.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Let the tests &quot;look under the hood&quot; and check pointers directly.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    The latter is usually the best solution, even for a simple class like &quot;DoublyLinkedList&quot; and especially for the more&#xD;
    complex classes that occur in your products.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Typically, tests are put in the same package as the class they test. They are given protected or friend access.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Approaches for Test Setup&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    To successfully run a test, the system must be in a known state. To do this you will need objects or components in&#xD;
    memory, rows in the database, etc. that you will test against. The easiest approach is to hardcode the required data&#xD;
    and the setup code within the test itself. The primary advantage is that all the information that you need about the&#xD;
    test is in one place and that the test is potentially self-sufficient.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Another approach is to define an external data set which is loaded into memory or into the database at the beginning of&#xD;
    the test run. There are several advantages to this approach:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It decouples the test data from the test.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        More than one test can use the same data set.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It is easy to modify and/or multiply the test data.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    There are some disadvantages to this approach:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Increased complexity for maintaining the external data&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Potential coupling between test cases. When they share a common test data bed it becomes very easy to write tests&#xD;
        that depend on other tests running first, thereby coupling them together.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Coding for Testability&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Add&amp;nbsp;&lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/termdefinitions/code_instrumentation_3060875F.html&quot;&#xD;
    guid=&quot;_lzAWkK9eEdyltJ0KgEd9WQ&quot;>code instrumentation&lt;/a> for testing and debugging. Pay special attention to the&#xD;
    implementation of the observation/control points, such as critical functions or objects, as these aspects might need&#xD;
    special support that has to be implemented in the application under test.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Reviewing Tests&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    If a test will be long-lived, ask a person with less inside knowledge of the implementation element to run it and check&#xD;
    if there is enough support information. Review it with other people within the development team and other interested&#xD;
    parties as needed.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;TestDesignMistakes&quot; name=&quot;TestDesignMistakes&quot;>&lt;/a>Characteristic Test Design Mistakes&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Each test exercises an implementation element and checks for correct results. The design of the test-the inputs it uses&#xD;
    and how it checks for correctness-can be good at revealing defects, or it can inadvertently hide them. Here are some&#xD;
    characteristic test design mistakes.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to specify expected results in advance&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Suppose you're testing an implementation element that converts XML into HTML. A temptation is to take some sample XML,&#xD;
    run it through the conversion, then look at the results in a browser. If the screen looks right, you &quot;bless&quot; the HTML&#xD;
    by saving it as the official expected results. Thereafter, a test compares the actual output of the conversion to the&#xD;
    expected results.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This is a dangerous practice. Even sophisticated computer users are used to believing what the computer does. You are&#xD;
    likely to overlook mistakes in the screen appearance. (Not to mention that browsers are quite tolerant of misformatted&#xD;
    HTML.) By making that incorrect HTML the official expected results, you make sure that the test can never find the&#xD;
    problem.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It's less dangerous to doubly-check by looking directly at the HTML, but it's still dangerous. Because the output is&#xD;
    complicated, it will be easy to overlook errors. You'll find more defects if you write the expected output by hand&#xD;
    first.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to check the background&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Tests usually check that what should have been changed has been, but their creators often forget to check that what&#xD;
    should have been left alone has been left alone. For example, suppose a program is supposed to change the first 100&#xD;
    records in a file. It's a good idea to check that the 101&lt;sup>st&lt;/sup> hasn't been changed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In theory, you would check that nothing in the &quot;background&quot;-the entire file system, all of memory, everything reachable&#xD;
    through the network-has been left alone. In practice, you have to choose carefully what you can afford to check. But&#xD;
    it's important to make that choice.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to check persistence&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Just because the implementation element tells you a change has been made, that doesn't mean it has actually been&#xD;
    committed to the database. You need to check the database via another route.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to add variety&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A test might be designed to check the effect of three fields in a database record, but many other fields need to be&#xD;
    filled in to execute the test. Testers will often use the same values over and over again for these &quot;irrelevant&quot;&#xD;
    fields. For example, they'll always use the name of their lover in a text field, or 999 in a numeric field.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The problem is that sometimes what shouldn't matter actually does. Every so often, there's a bug that depends on some&#xD;
    obscure combination of unlikely inputs. If you always use the same inputs, you stand no chance of finding such bugs. If&#xD;
    you persistently vary inputs, you might. Quite often, it costs almost nothing to use a number different than 999 or to&#xD;
    use someone else's name. When varying the values used in tests costs almost nothing and it has some potential benefit,&#xD;
    then vary. (Note: It's unwise to use names of old lovers instead of your current one if your current lover works with&#xD;
    you.)&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Here's another benefit. One plausible fault is for the program to use field &lt;i>X&lt;/i> when it should have used field&#xD;
    &lt;i>Y&lt;/i>. If both fields contain &quot;Dawn&quot;, the fault can't be detected.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to use realistic data&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    It's common to use made-up data in tests. That data is often unrealistically simple. For example, customer names might&#xD;
    be &quot;Mickey&quot;, &quot;Snoopy&quot;, and &quot;Donald&quot;. Because that data is different from what real users enter - for example, it's&#xD;
    characteristically shorter - it can miss defects real customers will see. For example, these one-word names wouldn't&#xD;
    detect that the code doesn't handle names with spaces.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It's prudent to make a slight extra effort to use realistic data.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to notice that the code does nothing at all&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Suppose you initialize a database record to zero, run a calculation that should result in zero being stored in the&#xD;
    record, then check that the record is zero. What has your test demonstrated? The calculation might not have taken place&#xD;
    at all. Nothing might have been stored, and the test couldn't tell.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    That example sounds unlikely. But this same mistake can crop up in subtler ways. For example, you might write a test&#xD;
    for a complicated installer program. The test is intended to check that all temporary files are removed after a&#xD;
    successful installation. But, because of all the installer options, in that test, one particular temporary file wasn't&#xD;
    created. Sure enough, that's the one the program forgot to remove.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Failure to notice that the code does the wrong thing&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Sometimes a program does the right thing for the wrong reasons. As a trivial example, consider this code:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;pre>&#xD;
&lt;!-- START NON-TRANSLATABLE -->&#xD;
if (a &amp;lt; b &amp;amp;&amp;amp; c) &#xD;
return 2 * x;&#xD;
else&#xD;
return x * x;&#xD;
&lt;!-- END NON-TRANSLATABLE -->&#xD;
&lt;/pre>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    The logical expression is wrong, and you've written a test that causes it to evaluate incorrectly and take the wrong&#xD;
    branch. Unfortunately, purely by coincidence, the variable X has the value 2 in that test. So the result of the wrong&#xD;
    branch is accidentally correct - the same as the result the right branch would have given.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For each expected result, you should ask if there's a plausible way in which that result could be&amp;nbsp;achieved for the&#xD;
    wrong reason. While it's often impossible to know, sometimes it's not.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
