| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q" name="new_concept,_aFeZgJquEdukqcRKZBQN9w" guid="-Ff1JwbrGt1laexkOB6ZM1Q" changeDate="2007-01-03T17:00:23.980-0500" version="1.0.0"> |
| <mainDescription><p> |
| Developer testing is the act of regression testing source code by developers.&nbsp; This is sometimes called "unit |
| regression testing" but many developer tests go beyond unit testing to address integration testing instead. |
| </p> |
| <h3> |
| Testing Philosophies |
| </h3> |
| <p> |
| Here are some important philosophies with regard to developer&nbsp;testing: |
| </p> |
| <ol> |
| <li> |
| The goal is to find defects. Successful tests find bugs, but correcting the bugs&nbsp;falls into other areas. |
| </li> |
| <li> |
| Test&nbsp;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_basic/guidances/concepts/test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw.html" |
| guid="_0Y6kUMlgEdmt3adZL5Dmdw">Concept: 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&nbsp;say that your application works, but until you show the test |
| results&nbsp;you might&nbsp;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&nbsp;a good developer test: |
| <ul class="noindent"> |
| <li> |
| It runs fast.&nbsp;It has&nbsp;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. E.g. Use copies of production data when appropriate, but remember that you'll also 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.&nbsp; To do this you will need objects or components |
| in memory, rows in your database, etc.&nbsp;that you will test against.&nbsp; The easiest approach is to hardcode the |
| required data and the setup code within the test itself.&nbsp; The primary advantage&nbsp;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&nbsp;is loaded into memory or into&nbsp;the database at the |
| beginning of&nbsp;the test run.&nbsp; There are several advantages to this approach: |
| </p> |
| <ul> |
| <li> |
| It decouples the test data from the test.&nbsp; |
| </li> |
| <li> |
| More than one test&nbsp;can use the same data set.&nbsp; |
| </li> |
| <li> |
| It is easy to modify and/or multiply the test data.&nbsp; |
| </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.&nbsp; When&nbsp;they share a common test data bed it becomes very easy to |
| write tests&nbsp;that depend on other tests running first, thereby coupling them together.<br /> |
| </li> |
| </ul> |
| <h3> |
| Coding for Testability |
| </h3> |
| <p> |
| Add&nbsp;<a class="elementLink" |
| href="./../../../openup_basic/guidances/termdefinitions/code_instrumentation,_JiqnEJt1EdutoZjlV3a4Lg.html" |
| guid="_JiqnEJt1EdutoZjlV3a4Lg">Code Instrumentation</a> for testing and debugging.&nbsp; Pay special attention to the |
| implementation of the observation/control points, such as critical functions or&nbsp;objects,&nbsp;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> |