| <?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><p>
 |
| Developer testing is the act of regression testing source code by developers. This is sometimes called "unit regression
 |
| testing" but many developer tests go beyond unit testing to address integration testing as well.
 |
| </p>
 |
| <h3>
 |
| Testing Philosophies
 |
| </h3>
 |
| <p>
 |
| Here are some important philosophies with regard to developer testing:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| The goal is to find defects. Successful tests find bugs, but correcting the bugs falls into other areas.
 |
| </li>
 |
| <li>
 |
| Test early and often. The cost of change rises exponentially the longer it takes to find and then remove a defect.
 |
| The implication is that you want to test as early as possible.
 |
| </li>
 |
| <li>
 |
| Testing builds confidence. Many people fear making a change to their code because they are afraid that they will
 |
| break it, but with a full test suite in place if you do break something you know you will detect it and then fix
 |
| it.
 |
| </li>
 |
| <li>
 |
| One test is worth a thousand opinions. You can say that your application works, but until you show the test results
 |
| you might not be believed.
 |
| </li>
 |
| <li>
 |
| Test to the risk. The riskier something is, the more it needs to be reviewed and tested. For example, you should
 |
| invest significantly more&nbsp;effort testing a safety-critical algorithm for measuring radiation doses, and far
 |
| less effort testing the "change font size" function of the same application.
 |
| </li>
 |
| <li>
 |
| You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of
 |
| this guidance is testing code.
 |
| </li>
 |
| </ol>
 |
| <h3>
 |
| Qualities of a Good Developer Test
 |
| </h3>These are the qualities of a good developer test: 
 |
| <ul class="noindent">
 |
| <li>
 |
| It runs fast. It has short setup, run time, and clean-up.
 |
| </li>
 |
| <li>
 |
| It runs in isolation. You should be able to reorder your tests.
 |
| </li>
 |
| <li>
 |
| It is understandable. Good tests have consistent and informative names and use data that makes them easy to read
 |
| and to understand.
 |
| </li>
 |
| <li>
 |
| It uses real data. For example, use copies of production data when appropriate, but remember that you'll typically
 |
| have to create some specific "artificial" test data as well.
 |
| </li>
 |
| <li>
 |
| It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and
 |
| one only issue.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
