OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/impl_developer_tests.xmi - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <org.eclipse.epf.uma:TaskDescription 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="_dWPe8KrMEdmqUqi7YGiSxw" name="impl_developer_tests,_0iL1EMlgEdmt3adZL5Dmdw" guid="_dWPe8KrMEdmqUqi7YGiSxw" changeDate="2007-01-15T17:54:27.434-0500" version="1.0.0">
   <mainDescription>&lt;p&gt;
     Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
     rather than being directly based on the system requirements.
 &lt;/p&gt;
 &lt;p&gt;
     It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
     course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
     etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
     additional behavior.
 &lt;/p&gt;</mainDescription>
   <keyConsiderations>&lt;ol&gt;
     &lt;li&gt;
         Automate tests via a unit regression testing tool (for example, xUnit) so that tests may be run by developers
         whenever they make changes to the code.
     &lt;/li&gt;
     &lt;li&gt;
         Test to the risk of the component. For example, the more critical a component is, the more important it is to test
         it thoroughly.
     &lt;/li&gt;
     &lt;li&gt;
         Pair with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html&quot;
         guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;&gt;Tester&lt;/a&gt; in all steps of this task to gain insight on testing and quality
         considerations.
     &lt;/li&gt;
 &lt;/ol&gt;</keyConsiderations>
   <sections xmi:id="_2LYo8KuPEdmhFZtkg1nakg" name="Refine scope and identify the test(s)" guid="_2LYo8KuPEdmhFZtkg1nakg">
     <sectionDescription>&lt;p&gt;
     Select the increment of work to be tested and identify developer test(s) to verify that the &lt;a class=&quot;elementLink&quot;
     href=&quot;./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html&quot;
     guid=&quot;_0YoQcMlgEdmt3adZL5Dmdw&quot;&gt;Implementation&lt;/a&gt; being developed behaves correctly. One source for the expected
     behavior for a software component is the &lt;a class=&quot;elementLink&quot;
     href=&quot;./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html&quot;
     guid=&quot;_0WuL8slgEdmt3adZL5Dmdw&quot;&gt;Design&lt;/a&gt;.&amp;nbsp;
 &lt;/p&gt;
 &lt;p&gt;
     In identifying the&amp;nbsp;tests or in any other part of this task, consider collaborating with a &lt;a class=&quot;elementLink&quot;
     href=&quot;./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;&gt;Tester&lt;/a&gt; who
     should be well-versed in the issues of testing.
 &lt;/p&gt;</sectionDescription>
   </sections>
   <sections xmi:id="_g8npoC5UEduVhuZHT5jKZQ" name="Write the test setup" guid="_g8npoC5UEduVhuZHT5jKZQ">
     <sectionDescription>To successfully run a test the system must be in a known state so that the correct behavior can be defined. Implement the
 setup logic that must be performed as part of the &lt;a class=&quot;elementLink&quot;
 href=&quot;./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html&quot;
 guid=&quot;_0YuXEclgEdmt3adZL5Dmdw&quot;&gt;Developer Test&lt;/a&gt;.</sectionDescription>
   </sections>
   <sections xmi:id="_g1eDUC5VEduVhuZHT5jKZQ" name="Define the expected results" guid="_g1eDUC5VEduVhuZHT5jKZQ">
     <sectionDescription>&lt;p&gt;
     Define the expected results of each test so that it can be verified.
 &lt;/p&gt;
 &lt;p&gt;
     After a test runs, you need to be able to compare the results of running the test against what was expected to happen.
     The test is successful when the actual results match the expected results.
 &lt;/p&gt;</sectionDescription>
   </sections>
   <sections xmi:id="_5WtVcKuPEdmhFZtkg1nakg" name="Write the test logic" guid="_5WtVcKuPEdmhFZtkg1nakg">
     <sectionDescription>Write the steps that perform the actual test(s).</sectionDescription>
   </sections>
   <sections xmi:id="_j30aAC5VEduVhuZHT5jKZQ" name="Define the test response" guid="_j30aAC5VEduVhuZHT5jKZQ">
     <sectionDescription>Define the information the test(s) must produce to successfully indicate success or failure. Consider if a response of True
 or False is sufficient, or if a detailed message should be logged as well.</sectionDescription>
   </sections>
   <sections xmi:id="_ku06gC5VEduVhuZHT5jKZQ" name="Write clean-up code" guid="_ku06gC5VEduVhuZHT5jKZQ">
     <sectionDescription>Identify, and then implement, the steps to be followed in order to restore the environment to the original state for each
 test. The goal is to ensure that there are no side effects from running the tests.</sectionDescription>
   </sections>
   <sections xmi:id="_6wZFMKuPEdmhFZtkg1nakg" name="Test the test" guid="_6wZFMKuPEdmhFZtkg1nakg">
     <sectionDescription>&lt;p&gt;
     Verify that each developer test works correctly. To do this:
 &lt;/p&gt;
 &lt;ul&gt;
     &lt;li&gt;
         Run the test(s), observe their behavior, and fix any defects in the tests.
     &lt;/li&gt;
     &lt;li&gt;
         Ensure that the expected results are defined properly and that they're being checked correctly.
     &lt;/li&gt;
     &lt;li&gt;
         Check the clean-up logic for each test.
     &lt;/li&gt;
     &lt;li&gt;
         Ensure that each developer test works within your test suite framework.
     &lt;/li&gt;
 &lt;/ul&gt;</sectionDescription>
   </sections>
   <purpose>Prepare to validate a software component (e.g. an operation, a class, a stored procedure) through unit testing. The result
 is one or more new developer tests.</purpose>
   <alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
 developer testing in identifying bugs and finding their location in the code.</alternatives>
 </org.eclipse.epf.uma:TaskDescription>
	<?xml version="1.0" encoding="UTF-8"?>
	<org.eclipse.epf.uma:TaskDescription 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="_dWPe8KrMEdmqUqi7YGiSxw" name="impl_developer_tests,_0iL1EMlgEdmt3adZL5Dmdw" guid="_dWPe8KrMEdmqUqi7YGiSxw" changeDate="2007-01-15T17:54:27.434-0500" version="1.0.0">
	<mainDescription><p>
	Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
	rather than being directly based on the system requirements.
	</p>
	<p>
	It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
	course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
	etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
	additional behavior.
	</p></mainDescription>
	<keyConsiderations><ol>
	<li>
	Automate tests via a unit regression testing tool (for example, xUnit) so that tests may be run by developers
	whenever they make changes to the code.
	</li>
	<li>
	Test to the risk of the component. For example, the more critical a component is, the more important it is to test
	it thoroughly.
	</li>
	<li>
	Pair with the <a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html"
	guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> in all steps of this task to gain insight on testing and quality
	considerations.
	</li>
	</ol></keyConsiderations>
	<sections xmi:id="_2LYo8KuPEdmhFZtkg1nakg" name="Refine scope and identify the test(s)" guid="_2LYo8KuPEdmhFZtkg1nakg">
	<sectionDescription><p>
	Select the increment of work to be tested and identify developer test(s) to verify that the <a class="elementLink"
	href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html"
	guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> being developed behaves correctly. One source for the expected
	behavior for a software component is the <a class="elementLink"
	href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
	guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>.&nbsp;
	</p>
	<p>
	In identifying the&nbsp;tests or in any other part of this task, consider collaborating with a <a class="elementLink"
	href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> who
	should be well-versed in the issues of testing.
	</p></sectionDescription>
	</sections>
	<sections xmi:id="_g8npoC5UEduVhuZHT5jKZQ" name="Write the test setup" guid="_g8npoC5UEduVhuZHT5jKZQ">
	<sectionDescription>To successfully run a test the system must be in a known state so that the correct behavior can be defined. Implement the
	setup logic that must be performed as part of the <a class="elementLink"
	href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
	guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>.</sectionDescription>
	</sections>
	<sections xmi:id="_g1eDUC5VEduVhuZHT5jKZQ" name="Define the expected results" guid="_g1eDUC5VEduVhuZHT5jKZQ">
	<sectionDescription><p>
	Define the expected results of each test so that it can be verified.
	</p>
	<p>
	After a test runs, you need to be able to compare the results of running the test against what was expected to happen.
	The test is successful when the actual results match the expected results.
	</p></sectionDescription>
	</sections>
	<sections xmi:id="_5WtVcKuPEdmhFZtkg1nakg" name="Write the test logic" guid="_5WtVcKuPEdmhFZtkg1nakg">
	<sectionDescription>Write the steps that perform the actual test(s).</sectionDescription>
	</sections>
	<sections xmi:id="_j30aAC5VEduVhuZHT5jKZQ" name="Define the test response" guid="_j30aAC5VEduVhuZHT5jKZQ">
	<sectionDescription>Define the information the test(s) must produce to successfully indicate success or failure. Consider if a response of True
	or False is sufficient, or if a detailed message should be logged as well.</sectionDescription>
	</sections>
	<sections xmi:id="_ku06gC5VEduVhuZHT5jKZQ" name="Write clean-up code" guid="_ku06gC5VEduVhuZHT5jKZQ">
	<sectionDescription>Identify, and then implement, the steps to be followed in order to restore the environment to the original state for each
	test. The goal is to ensure that there are no side effects from running the tests.</sectionDescription>
	</sections>
	<sections xmi:id="_6wZFMKuPEdmhFZtkg1nakg" name="Test the test" guid="_6wZFMKuPEdmhFZtkg1nakg">
	<sectionDescription><p>
	Verify that each developer test works correctly. To do this:
	</p>
	<ul>
	<li>
	Run the test(s), observe their behavior, and fix any defects in the tests.
	</li>
	<li>
	Ensure that the expected results are defined properly and that they're being checked correctly.
	</li>
	<li>
	Check the clean-up logic for each test.
	</li>
	<li>
	Ensure that each developer test works within your test suite framework.
	</li>
	</ul></sectionDescription>
	</sections>
	<purpose>Prepare to validate a software component (e.g. an operation, a class, a stored procedure) through unit testing. The result
	is one or more new developer tests.</purpose>
	<alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
	developer testing in identifying bugs and finding their location in the code.</alternatives>
	</org.eclipse.epf.uma:TaskDescription>