https://bugs.eclipse.org/bugs/show_bug.cgi?id=243938
diff --git a/libraries/EPF_Practices_Library/core.tech.common.base/guidances/concepts/developer_testing.xmi b/libraries/EPF_Practices_Library/core.tech.common.base/guidances/concepts/developer_testing.xmi
index ba4c47a..7844033 100644
--- a/libraries/EPF_Practices_Library/core.tech.common.base/guidances/concepts/developer_testing.xmi
+++ b/libraries/EPF_Practices_Library/core.tech.common.base/guidances/concepts/developer_testing.xmi
@@ -1,9 +1,9 @@
<?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"
+ 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
@@ -64,59 +64,5 @@
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>
+</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/libraries/EPF_Practices_Library/core.tech.common.base/guidances/guidelines/developer_testing.xmi b/libraries/EPF_Practices_Library/core.tech.common.base/guidances/guidelines/developer_testing.xmi
index 0bcfa74..6e4e80e 100644
--- a/libraries/EPF_Practices_Library/core.tech.common.base/guidances/guidelines/developer_testing.xmi
+++ b/libraries/EPF_Practices_Library/core.tech.common.base/guidances/guidelines/developer_testing.xmi
@@ -27,6 +27,9 @@
either proceed to the next change or fix the last change. Expect to spend some effort making that rapid feedback
possible.
</p>
+<h3>
+ Write and maintain&nbsp;tests
+</h3>
<h4>
Automate your tests
</h4>
@@ -311,6 +314,60 @@
<p>
Typically, tests are put in the same package as the class they test. They are given protected or friend access.
</p>
+<h4>
+ Approaches for Test Setup
+</h4>
+<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>
+<h4>
+ Coding for Testability
+</h4>
+<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>
+<h4>
+ Reviewing Tests
+</h4>
+<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>
<h3>
<a id="TestDesignMistakes" name="TestDesignMistakes"></a>Characteristic Test Design Mistakes
</h3>
