OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/concepts/test_first_design.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\test_first_design.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: test_first_design.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 3904523993 -->Test-first Design<!-- END:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 438527168 -->This concept explains how to bring test design chronologically in-line with software design.<!-- END:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg CRC: 449565311 --><h3>
     Introduction
 </h3>
 <p>
     With Test-First Design (TFD) you do detailed design in a just-in-time (JIT) manner&nbsp;via writing a single test
     before writing just enough production code to fulfill that test.&nbsp; When you have new functionality to add to your
     system, perform the following steps:
 </p>
 <ol>
     <li>
         <strong>Quickly add a test</strong>.&nbsp; You need just enough code to fail.&nbsp;
     </li>
     <li>
         <strong>Run your tests</strong>.&nbsp; You will&nbsp;typically run the complete test suite, although for sake of
         speed you may decide to run only a subset.&nbsp; The goal is&nbsp;to ensure that the new test does in fact
         fail.&nbsp;
     </li>
     <li>
         <strong>Update your production code</strong>.&nbsp;&nbsp;The goal is to add just enough functionality so that
         your&nbsp;code&nbsp;passes the new test.&nbsp;
     </li>
     <li>
         <strong>Run your test suite&nbsp;again</strong>.&nbsp; If they tests fail you need to update your functional code
         and retest.&nbsp; Once the tests pass, start over.&nbsp;
     </li>
 </ol>
 <br />
 <p>
     <img height="600" alt="Test First Design Flow" src="./resources/testFirstDesign.jpg" width="294" />&nbsp;
 </p>
 <h4>
     Why TFD?
 </h4>
 <p>
     A significant advantage of TFD is that it enables you to take small steps when writing software, which is not only
     safer it is also far more productive than writing code&nbsp;in large steps.<span     style="mso-spacerun: yes">&nbsp;</span> For example, assume you add some new functional code, compile, and test
     it.<span style="mso-spacerun: yes">&nbsp;</span> Chances are pretty good that your tests will be broken by defects that
     exist in the new code.<span style="mso-spacerun: yes">&nbsp;</span> It is much easier to find, and then fix, those
     defects if you've written five new lines of code than in fifty lines. The implication is that the faster your compiler
     and regression test suite, the more attractive it is to proceed in smaller and smaller steps.<span     style="mso-spacerun: yes">&nbsp;</span>
 </p>
 <p>
     There are three other common testing strategies (in order of effectiveness).
 </p>
 <ol>
     <li>
         <strong>Write&nbsp;several tests first</strong>.&nbsp; This is a variant of TFD where you write more than one test
         before writing just enough production code to fulfill those tests.&nbsp; The advantage is that you don't need to
         build your system as often,&nbsp;potentially saving time.&nbsp; It&nbsp;has the disadvantage that you will write
         more&nbsp;production code at once, increasing the difficulty of finding any new bugs that you do introduce.
     </li>
     <li>
         <strong>Test after the fact</strong>.&nbsp; With this approach you write some production code then you write enough
         testing code to validate it.&nbsp; This has the advantage that you're at least still validating the code but has
         the disadvantage that you lose the design benefit inherent in writing the testing code first.
     </li>
     <li>
         <strong>Don't test at all</strong>.&nbsp; This is a really bad idea.
     </li>
 </ol>
 <br />
 <h3>
     Good Things to Know
 </h3>
 <p>
     1. An underlying assumption of TDD is that you have a unit-testing framework available to you.<span     style="mso-spacerun: yes">&nbsp;</span> Agile software developers often use the xUnit family of open source tools, such
     as <a  href="http://www.junit.org/" ><strong>JUnit</strong></a> or <a  href="http://www.vbunit.org/" ><strong>VBUnit</strong></a>, although commercial tools are
     also viable options.<span style="mso-spacerun: yes">&nbsp;&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span>
 </p>
 <p>
     2. Test-Driven Design (TDD) = TFD + <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
 </p>
 <p>
     3. TFD/TDD is commonly used with object-oriented business code, although you can also take this approach with
     procedural code, user-interface code, and your database code if you choose to.
 </p>
 <p>
     4. A more thorough discussion of TFD and TDD is presented at <a  href="http://www.agiledata.org/essays/tdd.html" target="_blank" >Introduction to Test Driven Development (TDD)</a>.
 </p>
 <br /><!-- END:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg -->
 </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\test_first_design.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: test_first_design.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 3904523993 -->Test-first Design<!-- END:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 438527168 -->This concept explains how to bring test design chronologically in-line with software design.<!-- END:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg CRC: 449565311 --><h3>
	Introduction
	</h3>
	<p>
	With Test-First Design (TFD) you do detailed design in a just-in-time (JIT) manner via writing a single test
	before writing just enough production code to fulfill that test.  When you have new functionality to add to your
	system, perform the following steps:
	</p>
	<ol>
	<li>
	<strong>Quickly add a test</strong>.  You need just enough code to fail.
	</li>
	<li>
	<strong>Run your tests</strong>.  You will typically run the complete test suite, although for sake of
	speed you may decide to run only a subset.  The goal is to ensure that the new test does in fact
	fail.
	</li>
	<li>
	<strong>Update your production code</strong>.  The goal is to add just enough functionality so that
	your code passes the new test.
	</li>
	<li>
	<strong>Run your test suite again</strong>.  If they tests fail you need to update your functional code
	and retest.  Once the tests pass, start over.
	</li>
	</ol>
	<br />
	<p>
	<img height="600" alt="Test First Design Flow" src="./resources/testFirstDesign.jpg" width="294" />
	</p>
	<h4>
	Why TFD?
	</h4>
	<p>
	A significant advantage of TFD is that it enables you to take small steps when writing software, which is not only
	safer it is also far more productive than writing code in large steps.<span style="mso-spacerun: yes"> </span> For example, assume you add some new functional code, compile, and test
	it.<span style="mso-spacerun: yes"> </span> Chances are pretty good that your tests will be broken by defects that
	exist in the new code.<span style="mso-spacerun: yes"> </span> It is much easier to find, and then fix, those
	defects if you've written five new lines of code than in fifty lines. The implication is that the faster your compiler
	and regression test suite, the more attractive it is to proceed in smaller and smaller steps.<span style="mso-spacerun: yes"> </span>
	</p>
	<p>
	There are three other common testing strategies (in order of effectiveness).
	</p>
	<ol>
	<li>
	<strong>Write several tests first</strong>.  This is a variant of TFD where you write more than one test
	before writing just enough production code to fulfill those tests.  The advantage is that you don't need to
	build your system as often, potentially saving time.  It has the disadvantage that you will write
	more production code at once, increasing the difficulty of finding any new bugs that you do introduce.
	</li>
	<li>
	<strong>Test after the fact</strong>.  With this approach you write some production code then you write enough
	testing code to validate it.  This has the advantage that you're at least still validating the code but has
	the disadvantage that you lose the design benefit inherent in writing the testing code first.
	</li>
	<li>
	<strong>Don't test at all</strong>.  This is a really bad idea.
	</li>
	</ol>
	<br />
	<h3>
	Good Things to Know
	</h3>
	<p>
	1. An underlying assumption of TDD is that you have a unit-testing framework available to you.<span style="mso-spacerun: yes"> </span> Agile software developers often use the xUnit family of open source tools, such
	as <a href="http://www.junit.org/" ><strong>JUnit</strong></a> or <a href="http://www.vbunit.org/" ><strong>VBUnit</strong></a>, although commercial tools are
	also viable options.<span style="mso-spacerun: yes">  </span><span style="mso-spacerun: yes"> </span>
	</p>
	<p>
	2. Test-Driven Design (TDD) = TFD + <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
	</p>
	<p>
	3. TFD/TDD is commonly used with object-oriented business code, although you can also take this approach with
	procedural code, user-interface code, and your database code if you choose to.
	</p>
	<p>
	4. A more thorough discussion of TFD and TDD is presented at <a href="http://www.agiledata.org/essays/tdd.html" target="_blank" >Introduction to Test Driven Development (TDD)</a>.
	</p>
	<br /><!-- END:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg -->
	</body>
	</html>