<?xml version="1.0" encoding="UTF-8"?>
<commit>
  <added type="array"/>
  <modified type="array">
    <modified>
      <diff>@@ -2,7 +2,7 @@
   &lt;!--
     This file is a fully-functioning example test case. Try opening this file in Firefox, Safari,
     or Internet Explorer to see what a running test looks like.
-    This file demonstrates the the components involved in writing a simple test, such as:
+    This file demonstrates the components involved in writing a simple test, such as:
       * The necessary HTML to run a test (with the required &lt;script&gt; and &lt;link rel=&quot;stylesheet&quot;&gt; tags),
       * A &quot;custom matcher&quot; (i.e., a custom assertion) to make your tests more readable,
       * And, a simple test with the necessary boiler-plate code to get you up and running.
@@ -54,9 +54,9 @@
           });
         });
         
-        describe(&quot;an undefined variable&quot;, function() {
+        describe(&quot;numbers&quot;, function() {
           // Here is a use of the custom matcher defined above.
-          it(&quot;is not defined&quot;, function() {
+          it(&quot;either is or is not even&quot;, function() {
             expect(2).to(be_even);
             expect(3).to_not(be_even);
           });</diff>
      <filename>EXAMPLE.html</filename>
    </modified>
    <modified>
      <diff>@@ -101,10 +101,10 @@ A great test maximizes these features:
 
 * it provides **documentation**, explaining the intended functioning of the system as well as how the source code works;
 * it supports **ongoing development**, as you bit-by-bit write a failing test and make it pass;
-* it supports **refactoring** and **prevents regression**;
+* it supports later **refactoring** and **prevents regression** as you add other features;
 * and it **requires little modification** as the implementation of the system changes, especially changes to unrelated code.
 
-This section focuses principally on tests as documentation. **To provide documentation, as well as support future modification, a test should be readable and well organized.** Here are some recommendations on how to do it.
+This section focuses principally on tests as documentation. **To provide documentation, as well as support future modification, a test should be readable and well organized.** Here are some recommendations on how to do just that.
 
 ## Use Nested Describes to Express Context
 
@@ -288,11 +288,11 @@ Screw.Unit is designed from the ground-up to be extensible. For example, to add
 
 There are also events for the `loading` and `loaded` test code code, as well as just `before` and just `after` all tests are run:
 
-  $(Screw)
-    .bind('loading', function() {...})
-    .bind('loaded', function() {...})
-    .bind('before', function() {...})
-    .bind('after', function() {...})
+    $(Screw)
+      .bind('loading', function() {...})
+      .bind('loaded', function() {...})
+      .bind('before', function() {...})
+      .bind('after', function() {...})
 
 # Download
 </diff>
      <filename>README.markdown</filename>
    </modified>
  </modified>
  <removed type="array"/>
  <parents type="array">
    <parent>
      <id>e9d806c0b4704d36d2fd14b9b9bc6b893c5b69be</id>
    </parent>
  </parents>
  <author>
    <name>Nick Kallen</name>
    <email>nkallen@nick-kallens-computer-2.local</email>
  </author>
  <url>http://github.com/nkallen/screw-unit/commit/6b33c202bd9ec922861a8c3db03c01d4ecfa404a</url>
  <id>6b33c202bd9ec922861a8c3db03c01d4ecfa404a</id>
  <committed-date>2008-07-06T15:41:42-07:00</committed-date>
  <authored-date>2008-07-06T15:41:42-07:00</authored-date>
  <message>documentation</message>
  <tree>d2034c8d796493ee204b3991ba797205bf61d594</tree>
  <committer>
    <name>Nick Kallen</name>
    <email>nkallen@nick-kallens-computer-2.local</email>
  </committer>
</commit>
