[an error occurred while processing this directive]

<div id="Path">
  <a href="http://www.cs.brown.edu/">Brown CS</a> //
  <a href="/courses/cs190/index.shtml" title="CS190 Home">CS190 Home</a> //
  <a href="/courses/cs190/2007/assignments.shtml" title="Assignments">Assignments</a> //
  <a href="/courses/cs190/2007/assignments/testing.shtml" title="Testing">Testing</a>
</div>

<div id="Content">
  <h1>Testing Assignment</h1>

  <!-- Page content goes here -->

  <h2>Due: Monday, April 9, 2007</h2>

  <p>This assignment is intended to introduce you to the joys of testing and debugging.  The goal is to evaluate 
  how valuable two testing strategies are.  Keep track of how long you spend on steps #3 and #5. Each person in 
  the class should:</p>

  <ol>
    <li>Grab the <a href="minesweeper_testing2.tgz">Minesweeper</a> code. Even if you still have it from the 
    debugging assignment, you must do this again -- a different set of bugs has been introduced.</li>
    <li>
      Checkpoint the code in MineField.C: just make a copy, since we are not using source control for such 
      a small code base, and append "_v1.0" to the original to "tag" it.
      <ul>
        <li>If your last name alphabetically begins with L or earlier, do the remaining steps, 3 to 7, in order.  
        Otherwise, do those steps in the order 5, 6, 3, 4, 7.</li>
      </ul>
    </li>
    <li>Step through each line of code in gdb.  Follow the guidelines from 
    <a href="../documents/restricted/Writing%20Solid%20Code.pdf">Writing Solid Code, Chapter 4</a> on how to do 
    this.  The idea is to check variable values and other state information before and after execution of each 
    line and verify that the line did what you expected.  You will find bugs.  Fix them.  Continue the process.  
    Whatever lines you change or add you will need to step through <em>again</em>.</li>
    <li> When every line has been successfully stepped through, checkpoint the code again: this time, make a copy 
    of MineField.C (which you have now modified) and append "_v1.1" (or _v1.2 if your last name falls after L) to 
    your modified file to tag that version as well.  This completes the first testing strategy.</li>
    <li> Do a code review with someone else in the class.  Explain the structure of the code and what each line of 
    code is doing.  Ask your reviewer to be really certain that they understand what the code is doing.  Augment 
    your comments where they are confusing.  Fix any bugs that you find.</li>
    <li>When every line has been successfully reviewed, checkpoint the code again and tag the file appropriately 
    (as detailed in step 4).  This completes the second testing strategy.</li>
    <li>You will now have three versions of your code. Hand in:
      <ul>
        <li>The final version, MineField.C_v1.2</li>
        <li>Pairwise diffs (see the diff man page if you are unfamiliar with diff) for versions 0 vs. 1 and 1 vs. 
        2 of your code</li>
        <li>The amount of time you spent on steps 3 and 5</li>
        <li>What order you did the steps in</li>
        <li>Who did the code review with you</li>
        <li>Your opinion of the value of the two testing strategies. Remember, your opinion can't be wrong, only 
        missing.</li>
	<li>How does this process fit into an overall testing plan?  What else, generally, should you be doing
	to test your program?</li>
      </ul>
    </li>
  </ol>

  <!-- Page content ends here -->

</div>

[an error occurred while processing this directive]