| <?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.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q" |
| name="new_concept,_aFeZgJquEdukqcRKZBQN9w" guid="-Ff1JwbrGt1laexkOB6ZM1Q" changeDate="2007-01-03T14:00:23.980-0800" |
| version="1.0.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 (the earliest you could possibly test is first, see
 |
| <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/test_first_design_21C77ADF.html" guid="_0Y6kUMlgEdmt3adZL5Dmdw">Guideline: Test-first Design</a>).
 |
| </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. In other words you should
 |
| invest significant effort testing in the algorithm for estimating radiation doses but nowhere near as much 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 <a class="elementLink" href="./../../../openup/guidances/termdefinitions/code_instrumentation_E6BE9793.html" guid="_JiqnEJt1EdutoZjlV3a4Lg">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 component under test.
 |
| </p>
 |
| <h3>
 |
| Reviewing Tests
 |
| </h3>
 |
| <p>
 |
| 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
 |
| 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> |