| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-EOoqKeF2SEXao6XhNXBD-w" |
| name=",_ADwlAJRtEdyrdaw_xGakyw" guid="-EOoqKeF2SEXao6XhNXBD-w" changeDate="2008-08-11T09:09:21.312-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>
 |
| <h3>
 |
| Approaches for Test Setup
 |
| </h3>
 |
| <p>
 |
| To successfully run a test, the system must be in a known state. To do this you will need objects or components in
 |
| memory, rows in the database, etc. that you will test against. The easiest approach is to hardcode the required data
 |
| and the setup code within the test itself. The primary advantage is that all the information that you need about the
 |
| test is in one place and that the test is potentially self-sufficient.
 |
| </p>
 |
| <p>
 |
| Another approach is to define an external data set which is loaded into memory or into the database at the beginning of
 |
| the test run. There are several advantages to this approach:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| It decouples the test data from the test.
 |
| </li>
 |
| <li>
 |
| More than one test can use the same data set.
 |
| </li>
 |
| <li>
 |
| It is easy to modify and/or multiply the test data.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| There are some disadvantages to this approach:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Increased complexity for maintaining the external data
 |
| </li>
 |
| <li>
 |
| Potential coupling between test cases. When they share a common test data bed it becomes very easy to write tests
 |
| that depend on other tests running first, thereby coupling them together.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Coding for Testability
 |
| </h3>
 |
| <p>
 |
| Add&nbsp;<a class="elementLink"
 |
| href="./../../../core.tech.common.base/guidances/termdefinitions/code_instrumentation_3060875F.html"
 |
| guid="_lzAWkK9eEdyltJ0KgEd9WQ">code instrumentation</a> for testing and debugging. Pay special attention to the
 |
| implementation of the observation/control points, such as critical functions or objects, as these aspects might need
 |
| special support that has to be implemented in the iunder test.
 |
| </p>
 |
| <h3>
 |
| Reviewing Tests
 |
| </h3>
 |
| <p>
 |
| If a test will be long-lived, ask a person with less inside knowledge of the implementation element to run it and check
 |
| if there is enough support information. Review it with other people within the development team and other interested
 |
| parties as needed.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
