<?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.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q"
    name="new_concept,_aFeZgJquEdukqcRKZBQN9w" guid="-Ff1JwbrGt1laexkOB6ZM1Q" changeDate="2007-01-03T14:00:23.980-0800"
    version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    Developer testing is the act of regression testing source code by developers. This is sometimes called &quot;unit regression&#xD;
    testing&quot; but many developer tests go beyond unit testing to address integration testing as well.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Testing Philosophies&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Here are some important philosophies with regard to developer testing:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        The goal is to find defects. Successful tests find bugs, but correcting the bugs falls into other areas.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Test early and often. The cost of change rises exponentially the longer it takes to find and then remove a defect.&#xD;
        The implication is that you want to test as early as possible (the earliest you could possibly test is first, see&#xD;
        &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/test_first_design_21C77ADF.html&quot; guid=&quot;_0Y6kUMlgEdmt3adZL5Dmdw&quot;>Guideline: Test-first Design&lt;/a>).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Testing builds confidence. Many people fear making a change to their code because they are afraid that they will&#xD;
        break it, but with a full test suite in place if you do break something you know you will detect it and then fix&#xD;
        it.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        One test is worth a thousand opinions. You can say that your application works, but until you show the test results&#xD;
        you might not be believed.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Test to the risk. The riskier something is, the more it needs to be reviewed and tested. In other words you should&#xD;
        invest significant effort testing in the algorithm for estimating radiation doses but nowhere near as much effort&#xD;
        testing the &quot;change font size&quot; function of the same application.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of&#xD;
        this guidance is testing code.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h3>&#xD;
    Qualities of a Good Developer Test&#xD;
&lt;/h3>These are the qualities of a good developer test: &#xD;
&lt;ul class=&quot;noindent&quot;>&#xD;
    &lt;li>&#xD;
        It runs fast. It has short setup, run time, and clean-up.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It runs in isolation. You should be able to reorder your tests.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It is understandable. Good tests have consistent and informative names and use data that makes them easy to read&#xD;
        and to understand.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It uses real data. For example, use copies of production data when appropriate, but remember that you'll typically&#xD;
        have to create some specific &quot;artificial&quot; test data as well.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and&#xD;
        one only issue.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Approaches for Test Setup&#xD;
&lt;/h3>&#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;h3>&#xD;
    Coding for Testability&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Add &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/termdefinitions/code_instrumentation_E6BE9793.html&quot; guid=&quot;_JiqnEJt1EdutoZjlV3a4Lg&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 component under test.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Reviewing Tests&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    If a test will be long-lived, ask a person with less inside knowledge of the component to run it and check if there is&#xD;
    enough support information. Review it with other people within the development team and other interested parties as&#xD;
    needed.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>