<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_Hg5UUMPbEdmbOvqy4O0adg" name="test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw" guid="_Hg5UUMPbEdmbOvqy4O0adg" changeDate="2006-08-15T17:49:28.248-0700">
  <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
&lt;p&gt;
    With Test-First Design (TFD) you do detailed design in a just-in-time (JIT) manner&amp;nbsp;via writing a single test
    before writing just enough production code to fulfill that test.&amp;nbsp; When you have new functionality to add to your
    system, perform the following steps:
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        &lt;strong&gt;Quickly add a test&lt;/strong&gt;.&amp;nbsp; You need just enough code to fail.&amp;nbsp;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Run your tests&lt;/strong&gt;.&amp;nbsp; You will&amp;nbsp;typically run the complete test suite, although for sake of
        speed you may decide to run only a subset.&amp;nbsp; The goal is&amp;nbsp;to ensure that the new test does in fact
        fail.&amp;nbsp;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Update your production code&lt;/strong&gt;.&amp;nbsp;&amp;nbsp;The goal is to add just enough functionality so that
        your&amp;nbsp;code&amp;nbsp;passes the new test.&amp;nbsp;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Run your test suite&amp;nbsp;again&lt;/strong&gt;.&amp;nbsp; If they tests fail you need to update your functional code
        and retest.&amp;nbsp; Once the tests pass, start over.&amp;nbsp;
    &lt;/li&gt;
&lt;/ol&gt;
&lt;br /&gt;
&lt;p&gt;
    &lt;img height=&quot;600&quot; alt=&quot;Test First Design Flow&quot; src=&quot;./resources/testFirstDesign.jpg&quot; width=&quot;294&quot; /&gt;&amp;nbsp;
&lt;/p&gt;
&lt;h4&gt;
    Why TFD?
&lt;/h4&gt;
&lt;p&gt;
    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&amp;nbsp;in large steps.&lt;span     style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt; For example, assume you add some new functional code, compile, and test
    it.&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt; Chances are pretty good that your tests will be broken by defects that
    exist in the new code.&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt; 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.&lt;span     style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt;
&lt;/p&gt;
&lt;p&gt;
    There are three other common testing strategies (in order of effectiveness).
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        &lt;strong&gt;Write&amp;nbsp;several tests first&lt;/strong&gt;.&amp;nbsp; This is a variant of TFD where you write more than one test
        before writing just enough production code to fulfill those tests.&amp;nbsp; The advantage is that you don't need to
        build your system as often,&amp;nbsp;potentially saving time.&amp;nbsp; It&amp;nbsp;has the disadvantage that you will write
        more&amp;nbsp;production code at once, increasing the difficulty of finding any new bugs that you do introduce.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Test after the fact&lt;/strong&gt;.&amp;nbsp; With this approach you write some production code then you write enough
        testing code to validate it.&amp;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.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Don't test at all&lt;/strong&gt;.&amp;nbsp; This is a really bad idea.
    &lt;/li&gt;
&lt;/ol&gt;
&lt;br /&gt;
&lt;h3&gt;
    Good Things to Know
&lt;/h3&gt;
&lt;p&gt;
    1. An underlying assumption of TDD is that you have a unit-testing framework available to you.&lt;span     style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt; Agile software developers often use the xUnit family of open source tools, such
    as &lt;a  href=&quot;http://www.junit.org/&quot; &gt;&lt;strong&gt;JUnit&lt;/strong&gt;&lt;/a&gt; or &lt;a  href=&quot;http://www.vbunit.org/&quot; &gt;&lt;strong&gt;VBUnit&lt;/strong&gt;&lt;/a&gt;, although commercial tools are
    also viable options.&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&amp;nbsp;&lt;/span&gt;&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt;
&lt;/p&gt;
&lt;p&gt;
    2. Test-Driven Design (TDD) = TFD + &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html&quot; guid=&quot;_Poc7IPDzEdqYgerqi84oCA&quot;&gt;Refactoring&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    4. A more thorough discussion of TFD and TDD is presented at &lt;a  href=&quot;http://www.agiledata.org/essays/tdd.html&quot; target=&quot;_blank&quot; &gt;Introduction to Test Driven Development (TDD)&lt;/a&gt;.
&lt;/p&gt;
&lt;br /&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>