<?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" epf:version="1.0.0" xmi:id="-3AbfvnHrCOIQS63sEjrOew" name="test-first_design,6.556259235358794E-306" guid="-3AbfvnHrCOIQS63sEjrOew" changeDate="2006-11-13T15:58:35.617-0800" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_test__developer_testing__test-first_design&quot; name=&quot;XE_test__developer_testing__test-first_design&quot;&gt;&lt;/a&gt;&lt;a
id=&quot;XE_design__test-first_design&quot; name=&quot;XE_design__test-first_design&quot;&gt;&lt;/a&gt; 
&lt;h3&gt;
    &lt;a id=&quot;Introduction&quot; name=&quot;Introduction&quot;&gt;Introduction&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    Test designs are created using information from a variety of artifacts, including design artifacts such as use case
    realizations, design models, or classifier interfaces. Tests are executed after components are created. It's typical to
    create the test designs just before the tests are to be executed - well after the software design artifacts are
    created. Figure 1, following, shows an example. Here, test design begins sometime toward the end of implementation. It
    draws on the results of component design. The arrow from Implementation to Test Execution indicates that the tests
    can't be executed until the implementation is complete.
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;159&quot; alt=&quot;&quot; src=&quot;resources/tstfrsdsg-img1.gif&quot; width=&quot;614&quot; /&gt;
&lt;/p&gt;
&lt;p class=&quot;picturetext&quot;&gt;
    Fig1: Traditionally, Test Design is performed later in the life-cycle
&lt;/p&gt;
&lt;p&gt;
    However, it doesn't have to be this way. Although test execution has to wait until the component has been implemented,
    test design can be done earlier. It could be done just after the design artifact is completed. It could even be done in
    parallel with component design, as shown here:
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;158&quot; alt=&quot;&quot; src=&quot;resources/tstfrsdsg-img2.gif&quot; width=&quot;610&quot; /&gt;
&lt;/p&gt;
&lt;p class=&quot;picturetext&quot;&gt;
    Fig2: Test-first Design brings test design chronologically in-line with software design
&lt;/p&gt;
&lt;p&gt;
    Moving the test effort &quot;upstream&quot; in this way is commonly called &quot;test-first design&quot;. What are its advantages?
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        No matter how carefully you design software, you'll make mistakes. You might be missing a relevant fact. Or you
        might have particular habits of thought that make it hard for you to see certain alternatives. Or you might just be
        tired and overlook something. Having other people review your design artifacts helps. They might have the facts you
        miss, or they might see what you overlooked. It's best if these people have a different perspective than you do; by
        looking at the design differently, they'll see things you missed.&lt;br /&gt;
        &lt;br /&gt;
         Experience has shown that the testing perspective is an effective one. It's relentlessly concrete. During software
        design, it's easy to think of a particular field as &quot;displaying the title of the current customer&quot; and move on
        without really thinking about it. During test design, you must decide &lt;i&gt;specifically&lt;/i&gt; what that field will show
        when a customer who retired from the Navy and then obtained a law degree insists on referring to himself as
        &quot;Lieutenant Morton H. Throckbottle (Ret.), Esq.&quot; Is his title &quot;Lieutenant&quot; or &quot;Esquire&quot;?&lt;br /&gt;
        &lt;br /&gt;
         If test design is deferred until just before test execution, as in Figure 1, you'll probably waste money. A
        mistake in your software design will remain uncaught until test design, when some tester says, &quot;You know, I knew
        this guy from the Navy...&quot;, creates the &quot;Morton&quot; test, and discovers the problem. Now a partially or fully complete
        implementation has to be rewritten and a design artifact has to be updated. It would be cheaper to catch the
        problem before implementation begins.&lt;br /&gt;
    &lt;/li&gt;
    &lt;li&gt;
        Some mistakes might be caught before test design. Instead, they'll be caught by the Implementer. That's still bad.
        Implementation must grind to a halt while the focus switches from how to implement the design to what that design
        should be. That's disruptive even when the Implementer and Designer roles are filled by the same person; it's much
        more disruptive when they're different people. Preventing this disruption is another way in which test-first design
        helps improve efficiency.&lt;br /&gt;
    &lt;/li&gt;
    &lt;li&gt;
        Test designs help Implementers in another way-by clarifying design. If there's a question in the Implementer's mind
        about what the design meant, the test design might serve as a specific example of the desired behavior. That will
        lead to fewer bugs due to Implementer misunderstanding.&lt;br /&gt;
    &lt;/li&gt;
    &lt;li&gt;
        There are fewer bugs even if the question &lt;i&gt;wasn't&lt;/i&gt; in the Implementer's mind - but should have been. For
        example, there might have been an ambiguity that the Designer unconsciously interpreted one way and the Implementer
        another. If the Implementer is working from both the design and also from specific instructions about what the
        component is supposed to do - from test cases - the component is more likely to actually do what is required.
    &lt;/li&gt;
&lt;/ol&gt;
&lt;h3&gt;
    &lt;a id=&quot;Examples&quot; name=&quot;Examples&quot;&gt;Examples&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    Here are some examples to give you the flavor of test-first design.
&lt;/p&gt;
&lt;p&gt;
    Suppose you're creating a system to replace the old &quot;ask the secretary&quot; method of assigning meeting rooms. One of the
    methods of the &lt;font size=&quot;+0&quot;&gt;MeetingDatabase&lt;/font&gt; class is called &lt;font size=&quot;+0&quot;&gt;getMeeting&lt;/font&gt;, which has this
    signature:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
Meeting getMeeting(Person, Time);
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    Given a person and a time, &lt;font size=&quot;+0&quot;&gt;getMeeting&lt;/font&gt; returns the meeting that person is scheduled to be in at
    that time. If the person isn't scheduled for anything, it returns the special &lt;font size=&quot;+0&quot;&gt;Meeting&lt;/font&gt; object
    &lt;font size=&quot;+0&quot;&gt;unscheduled&lt;/font&gt;. There are some straightforward test cases:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        The person isn't in any meeting at the given time. Is the &lt;font size=&quot;+0&quot;&gt;unscheduled&lt;/font&gt; meeting returned?
    &lt;/li&gt;
    &lt;li&gt;
        The person is in a meeting at that time. Does the method return the correct meeting?
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    These test cases are unexciting, but they need to be tried eventually. They might as well be created now, by writing
    the actual test code that will someday be run. Java code for the first test might look like this:
&lt;/p&gt;
&lt;pre&gt;
    // if not in a meeting at given time,
    // expect to be unscheduled.
    public void testWhenAvailable() {
Person fred = new Person(&quot;fred&quot;);
Time now = Time.now();
MeetingDatabase db = new MeetingDatabase();
expect(db.getMeeting(fred, now) == Meeting.unscheduled);
    }
&lt;/pre&gt;
&lt;p&gt;
    But there are more interesting test ideas. For example, this method searches for a match. Whenever a method searches,
    it's a good idea to ask what should happen if the search finds more than one match. In this case, that means asking
    &quot;Can a person be in two meetings at once?&quot; Seems impossible, but asking the secretary about that case might reveal
    something surprising. It turns out that some executives are quite often scheduled into two meetings at once. Their role
    is to pop into a meeting, &quot;rally the troops&quot; for some short amount of time, and then move on. A system that didn't
    accommodate that behavior would go at least partially unused.
&lt;/p&gt;
&lt;p&gt;
    This is an example of test-first design done at the implementation level catching an analysis problem. There are a few
    things to note about that:
&lt;/p&gt;
&lt;ol&gt;
    &lt;li&gt;
        You would hope that good use-case specification and analysis would have already discovered this requirement. In
        that case, the problem would have been avoided &quot;upstream&quot; and &lt;font size=&quot;+0&quot;&gt;getMeeting&lt;/font&gt; would have been
        designed differently. (It couldn't return a meeting; it would have to return a set of meetings.) But analysis
        always misses some problems, and it's better for them to be discovered during implementation than after
        deployment.&lt;br /&gt;
    &lt;/li&gt;
    &lt;li&gt;
        In many cases, Designers and Implementers won't have the domain knowledge to catch such problems - they won't have
        the opportunity or time to quiz the secretary. In that case, the person designing tests for &lt;font
        size=&quot;+0&quot;&gt;getMeeting&lt;/font&gt; would ask, &quot;is there a case in which two meetings should be returned?&quot;, think for a
        while, and conclude that there wasn't. So test-first design doesn't catch every problem, but the mere fact of
        asking the right kinds of questions increases the chance a problem will be found.&lt;br /&gt;
    &lt;/li&gt;
    &lt;li&gt;
        Some of the same testing techniques that apply during implementation also apply to analysis. Test-first design can
        be done by analysts as well, but that's not the topic of this page.
    &lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;
    The second of the three examples is a statechart model for a heating system.
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;253&quot; alt=&quot;&quot; src=&quot;resources/tstfrsdsg-img3.gif&quot; width=&quot;567&quot; /&gt;
&lt;/p&gt;
&lt;p class=&quot;picturetext&quot;&gt;
    Fig3: HVAC Statechart
&lt;/p&gt;
&lt;p&gt;
    A set of tests would traverse all the arcs in the statechart. One test might begin with an idle system, inject a Too
    Hot event, fail the system during the Cooling/Running state, clear the failure, inject another Too Hot event, then run
    the system back to the Idle state. Since that does not exercise all the arcs, more tests are needed. These kinds of
    tests look for various kinds of implementation problems. For example, by traversing every arc, they check whether the
    implementation has left one out. By using sequences of events that have failure paths followed by paths that should
    successfully complete, they check whether error-handling code fails to clean up partial results that might affect later
    computation. (For more about testing statecharts, see &lt;a class=&quot;elementLinkWithUserText&quot;
    href=&quot;./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html&quot;
    guid=&quot;1.0347051690476123E-305&quot;&gt;Guideline: Test Ideas for Statechart and Activity Diagrams&lt;/a&gt;.)
&lt;/p&gt;
&lt;p&gt;
    The final example uses part of a design model. There's an association between a creditor and an invoice, where any
    given creditor can have more than one invoice outstanding.
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;45&quot; alt=&quot;&quot; src=&quot;resources/tstfrsdsg-img4.gif&quot; width=&quot;186&quot; /&gt;
&lt;/p&gt;
&lt;p class=&quot;picturetext&quot;&gt;
    Fig4: Association between Creditor and Invoice Classes
&lt;/p&gt;
&lt;p&gt;
    Tests based on this model would exercise the system when a creditor has no invoices, one invoice, and a large number of
    invoices. A tester would also ask whether there are situations in which an invoice might need to be associated with
    more than one creditor, or where an invoice has no creditor. (Perhaps the people who currently run the paper-based
    system the computer system is to replace use creditor-less invoices as a way to keep track of pending work). If so,
    that would be another problem that should have been caught in Analysis.
&lt;/p&gt;
&lt;h3&gt;
    &lt;a id=&quot;WhoDoesTest-FirstDesign&quot; name=&quot;WhoDoesTest-FirstDesign&quot;&gt;Who does test-first design?&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    Test-first design can be done by either the author of the design or by someone else. It's common for the author to do
    it. The advantage is that it reduces communication overhead. The Designer and Test Designer don't have to explain
    things to each other. Further, a separate Test Designer would have to spend time learning the design well, whereas the
    original Designer already knows it. Finally, many of these questions - like &quot;what happens if the compressor fails in
    state X?&quot; - are natural questions to ask during both software artifact design and test design, so you might as well
    have the same person ask them exactly once and write the answers down in the form of tests.
&lt;/p&gt;
&lt;p&gt;
    There are disadvantages, though. The first is that the Designer is, to some extent, blind to his or her own mistakes.
    The test design process will reveal some of that blindness, but probably not as much as a different person would find.
    How much of a problem this is seems to vary widely from person to person and is often related to the amount of
    experience the Designer has.
&lt;/p&gt;
&lt;p&gt;
    Another disadvantage of having the same person do both software design and test design is that there's no parallelism.
    Whereas allocating the roles to separate people will take more total effort, it will probably result in less elapsed
    calendar time. If people are itching to move out of design and into implementation, taking time for test design can be
    frustrating. More importantly, there's a tendency to skimp on the work in order to move on.
&lt;/p&gt;
&lt;h3&gt;
    &lt;a id=&quot;CanAllTestDesignBeDoneAtComponentDesignTime&quot; name=&quot;CanAllTestDesignBeDoneAtComponentDesignTime&quot;&gt;Can all test
    design be done at component design time?&lt;/a&gt;
&lt;/h3&gt;
&lt;p&gt;
    No. The reason is that not all decisions are made at design time. Decisions made during implementation won't be
    well-tested by tests created from the design. The classic example of this is a routine to sort arrays. There are many
    different sorting algorithms with different tradeoffs. Quicksort is usually faster than an insertion sort on large
    arrays, but often slower on small arrays. So a sorting algorithm might be implemented to use Quicksort for arrays with
    more than 15 elements, but insertion sort otherwise. That division of labor might be invisible from design artifacts.
    You &lt;i&gt;could&lt;/i&gt; represent it in a design artifact, but the Designer might have decided that the benefit of making such
    explicit decisions wasn't worthwhile. Since the size of the array plays no role in the design, the test design might
    inadvertently use only small arrays, meaning that none of the Quicksort code would be tested at all.
&lt;/p&gt;
&lt;p&gt;
    As another example, consider this fraction of a sequence diagram. It shows a &lt;font size=&quot;+0&quot;&gt;SecurityManager&lt;/font&gt;
    calling the &lt;font size=&quot;+0&quot;&gt;log()&lt;/font&gt; method of &lt;font size=&quot;+0&quot;&gt;StableStore&lt;/font&gt;. In this case, though, the &lt;font
    size=&quot;+0&quot;&gt;log()&lt;/font&gt; returns a failure, which causes &lt;font size=&quot;+0&quot;&gt;SecurityManager&lt;/font&gt; to call &lt;font
    size=&quot;+0&quot;&gt;Connection.close()&lt;/font&gt;.
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt;
    &lt;img height=&quot;161&quot; alt=&quot;&quot; src=&quot;resources/tstfrsdsg-img5.gif&quot; width=&quot;303&quot; /&gt;
&lt;/p&gt;
&lt;p class=&quot;picturetext&quot;&gt;
    Fig5: SecurityManager sequence diagram instance
&lt;/p&gt;
&lt;p&gt;
    This is a good reminder to the Implementer. Whenever &lt;font size=&quot;+0&quot;&gt;log()&lt;/font&gt; fails, the connection must be closed.
    The question for testing to answer is whether the Implementer really did it-and did it correctly-in &lt;i&gt;all&lt;/i&gt; cases or
    just in &lt;i&gt;some&lt;/i&gt;. To answer the question, the Test Designer must find all the calls to &lt;font
    size=&quot;+0&quot;&gt;StableStore.log()&lt;/font&gt; and make sure each of those call points is given a failure to handle.
&lt;/p&gt;
&lt;p&gt;
    It might seem odd to run such a test, given that you've just looked at all the code that calls &lt;font
    size=&quot;+0&quot;&gt;StableStore.log()&lt;/font&gt;. Can't you just check to see if it handles failure correctly?
&lt;/p&gt;
&lt;p&gt;
    Perhaps inspection might be enough. But error-handling code is notoriously error-prone because it often implicitly
    depends on assumptions that the existence of the error has violated. The classic example of this is code that handles
    allocation failures. Here's an example:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;pre&gt;
while (true) { // top level event loop
    try {
XEvent xe = getEvent();
...                      // main body of program
    } catch (OutOfMemoryError e) {
emergencyRestart();
    }
}
&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    This code attempts to recover from out of memory errors by cleaning up (thus making memory available) and then
    continuing to process events. Let's suppose that's an acceptable design. &lt;font size=&quot;+0&quot;&gt;emergencyRestart&lt;/font&gt; takes
    great care not to allocate memory. The problem is that &lt;font size=&quot;+0&quot;&gt;emergencyRestart&lt;/font&gt; calls some utility
    routine, which calls some other utility routine, which calls some other utility routine-which allocates a new object.
    Except that there's no memory, so the whole program fails. These kinds of problems are hard to find through inspection.
&lt;/p&gt;
&lt;h3&gt;
    &lt;a id=&quot;Test-FirstDesignAndRUPPhases&quot; name=&quot;Test-FirstDesignAndRUPPhases&quot;&gt;Test-first design and the phases
    of&amp;nbsp;Unified&lt;/a&gt; Process
&lt;/h3&gt;
&lt;p&gt;
    Up to this point, we've implicitly assumed that you'd do as much test design as possible as early as possible. That is,
    you'd derive all the tests you could from the design artifact, later adding only tests based on implementation
    internals. That may not be appropriate in the Elaboration phase, because such complete testing may not be aligned with
    an iteration's objectives.
&lt;/p&gt;
&lt;p&gt;
    Suppose an architectural prototype is being built to demonstrate product feasibility to investors. It might be based on
    a few key use-case instances. Code should be tested to see that it supports them. But is there any harm if further
    tests are created? For example, it might be obvious that the prototype ignores important error cases. Why not document
    the need for that error handling by writing test cases that will exercise it?
&lt;/p&gt;
&lt;p&gt;
    But what if the prototype does its job and reveals that the architectural approach won't work? Then the architecture
    will be thrown away - along with all those tests for error-handling. In that case, the effort of designing the tests
    will have yielded no value. It would have been better to have waited, and only designed those tests needed to check
    whether this proof-of-concept prototype really proves the concept.
&lt;/p&gt;
&lt;p&gt;
    This may seem a minor point, but there are strong psychological effects in play. The Elaboration phase is about
    addressing major risks. The whole project team should be focused on those risks. Having people concentrating on minor
    issues drains focus and energy from the team.
&lt;/p&gt;
&lt;p&gt;
    So where might test-first design be used successfully in the Elaboration phase? It can play an important role in
    adequately exploring architectural risks. Considering how, precisely, the team will know if a risk has been realized or
    avoided will add clarity to the design process and may well result in a better architecture being built the first time.
&lt;/p&gt;
&lt;p&gt;
    During the Construction phase, design artifacts are put into their final form. All the required use-case realizations
    are implemented, as are the interfaces for all classes. Because the phase objective is completeness, complete
    test-first design is appropriate. Later events should invalidate few, if any, tests.
&lt;/p&gt;
&lt;p&gt;
    The Inception and Transition phases typically have less focus on design activities for which testing is appropriate.
    When it is, test-first design is applicable. For example, it could be used with candidate proof-of-concept work in
    Inception. As with Construction and Elaboration phase testing, it should be aligned with iteration objectives.
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>