OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/concepts/developer_testing.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\concepts\developer_testing.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: developer_testing.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_aFeZgJquEdukqcRKZBQN9w CRC: 302200055 -->Developer Testing<!-- END:presentationName,_aFeZgJquEdukqcRKZBQN9w -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_aFeZgJquEdukqcRKZBQN9w CRC: 3534768133 -->Developers regression test their code on a continuous basis to ensure that it works as expected.<!-- END:briefDescription,_aFeZgJquEdukqcRKZBQN9w -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-Ff1JwbrGt1laexkOB6ZM1Q CRC: 2975183953 --><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><!-- END:mainDescription,-Ff1JwbrGt1laexkOB6ZM1Q -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\concepts\developer_testing.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: developer_testing.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_aFeZgJquEdukqcRKZBQN9w CRC: 302200055 -->Developer Testing<!-- END:presentationName,_aFeZgJquEdukqcRKZBQN9w -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_aFeZgJquEdukqcRKZBQN9w CRC: 3534768133 -->Developers regression test their code on a continuous basis to ensure that it works as expected.<!-- END:briefDescription,_aFeZgJquEdukqcRKZBQN9w -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-Ff1JwbrGt1laexkOB6ZM1Q CRC: 2975183953 --><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 instead.
	</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_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 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. 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.  To do this you will need objects or components
	in memory, rows in your 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.<br />
	</li>
	</ul>
	<h3>
	Coding for Testability
	</h3>
	<p>
	Add <a class="elementLink"
	href="./../../../openup_basic/guidances/termdefinitions/code_instrumentation,_JiqnEJt1EdutoZjlV3a4Lg.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><!-- END:mainDescription,-Ff1JwbrGt1laexkOB6ZM1Q -->
	</body>
	</html>