<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="-EOoqKeF2SEXao6XhNXBD-w"
    name=",_ADwlAJRtEdyrdaw_xGakyw" guid="-EOoqKeF2SEXao6XhNXBD-w" changeDate="2008-08-12T17:15:16.733-0700"
    version="7.2.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.&#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. For example, you should&#xD;
        invest significantly more&amp;nbsp;effort testing a safety-critical algorithm for measuring radiation doses, and far&#xD;
        less effort 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></mainDescription>
</org.eclipse.epf.uma:ContentDescription>