adds key points

01-basics.html

@@ -39,8 +39,8 @@ <h2><span class="glyphicon glyphicon-certificate"></span>Learning Objectives</h2
 </ul>
 </div>
 </section>
-<p>Testing should be a seamless part of scientific software development process. The purpose of the software should be clear to anyone reading the tests. For this reason, the purpose of the software must be clear the person writing the test. Thus, tests should be created aroudnd the same time as the code in qustion. Similarly, the author of the original software is often the best person to write the tests for that software.</p>
-<p>At the beginning of a new project, tests can be used to help guide the overall architecture of the project. This is analogous to experiment design in the experimental science world. The act of writing tests can help clarify how the software should be performing. Taking this idea to the extreme you could start to write the tests <em>before</em> you even write the software that will be tested. Such a practice is called <em>test-driven development</em>, which we will discuss in greater detail <a href="09-tdd.html">later in the lesson</a>.</p>
+<p>The first step toward getting the right answers from our programs is to assume that mistakes <em>will</em> happen and to guard against them. This is called <strong>defensive programming</strong> and the most common way to do it is to add alarms and tests into our code so that it checks itself.</p>
+<p><strong>Testing</strong> should be a seamless part of scientific software development process. At the beginning of a new project, tests can be used to help guide the overall architecture of the project. This is analogous to experiment design in the experimental science world. The act of writing tests can help clarify how the software should be performing. Taking this idea to the extreme you could start to write the tests <em>before</em> you even write the software that will be tested. Such a practice is called <em>test-driven development</em>, which we will discuss in greater detail <a href="09-tdd.html">later in the lesson</a>.</p>
 <blockquote>
 <h3>What Kinds of Tests Exist</h3>
 <p>There are many ways to test software, such as:</p>
@@ -55,28 +55,18 @@ <h3>What Kinds of Tests Exist</h3>
 <p><em>Unit Tests</em>: Unit tests investigate the behavior of units of code (such as functions, classes, or data structures). By validating each software unit across the valid range of its input and output parameters, tracking down unexpected behavior that may appear when the units are combined is made vastly simpler.</p>
 <p><em>Regression Tests</em>: Regression tests defend against new bugs, or regressions, which might appear due to new software and updates.</p>
 <p><em>Integration Tests</em>: Integration tests check that various pieces of the software work together as expected.</p>
-<aside class="callout panel panel-info">
-<div class="panel-heading">
-<h2><span class="glyphicon glyphicon-pushpin"></span>Key Ideas</h2>
-</div>
-<div class="panel-body">
+<blockquote>
+<h2>Key Points</h2>
 <ul>
 <li>Tests compare that the result observed from running code is the same as what was expected ahead of time.</li>
 <li>Tests should be written at the same time as the code they are testing is written.</li>
 <li>The person best suited to write a test is the author of the original code.</li>
 <li>Assertions and exceptions are like alarm systems embedded in the software, guarding against exceptional bahavior.</li>
-<li><ul>
 <li>Unit tests try to test the smallest pieces of code possible, usually functions and methods.</li>
-</ul></li>
-<li><ul>
 <li>Integration tests make sure that code units work together properly.</li>
-</ul></li>
-<li><ul>
 <li>Regression tests ensure that everything works the same today as it did yesterday.</li>
-</ul></li>
 </ul>
-</div>
-</aside>
+</blockquote>
         </div>
       </div>
       </article>

01-basics.md

@@ -9,13 +9,12 @@ minutes: 5
 > *   Understand the place of testing in a scientific workflow.
 > *   Understand that testing has many forms.
 
-Testing should be a seamless part of scientific software development process.
-The purpose of the software should be clear to anyone reading the tests. For
-this reason, the purpose of the software must be clear the person writing the
-test. Thus, tests should be created aroudnd the same time as the code in
-qustion. Similarly, the author of the original software is often the best
-person to write the tests for that software.  
+The first step toward getting the right answers from our programs is to assume
+that mistakes *will* happen and to guard against them.  This is called
+**defensive programming** and the most common way to do it is to add alarms and
+tests into our code so that it checks itself.
 
+**Testing** should be a seamless part of scientific software development process.
 At the beginning of a new project, tests can
 be used to help guide the overall architecture of the project.
 This is analogous to experiment design in the experimental science world.
@@ -52,15 +51,13 @@ which might appear due to new software and updates.
 software work together as expected. 
 
 
-> ## Key Ideas {.callout}
+> ## Key Points {.keypoints}
 > 
-> * Tests compare that the result observed from running code is the same as what was
-  expected ahead of time.
-> * Tests should be written at the same time as the code they are testing is written.
-> * The person best suited to write a test is the author of the original code.
+> - Tests compare that the result observed from running code is the same as what was expected ahead of time.
+> - Tests should be written at the same time as the code they are testing is written.
+> - The person best suited to write a test is the author of the original code.
 > - Assertions and exceptions are like alarm systems embedded in the software, guarding against exceptional bahavior.
-- * Unit tests try to test the smallest pieces of code possible, usually functions and
-  methods.
-> - * Integration tests make sure that code units work together properly.
-> - * Regression tests ensure that everything works the same today as it did yesterday.
+> - Unit tests try to test the smallest pieces of code possible, usually functions and methods.
+> - Integration tests make sure that code units work together properly.
+> - Regression tests ensure that everything works the same today as it did yesterday.
 

02-assertions.html

@@ -36,7 +36,7 @@ <h2><span class="glyphicon glyphicon-certificate"></span>Learning Objectives</h2
 <ul>
 <li>Assertions are one line tests embedded in code.</li>
 <li>Assertions can halt execution if something unexpected happens.</li>
-<li>Assertions are the building block of tests.</li>
+<li>Assertions are the building blocks of tests.</li>
 </ul>
 </div>
 </section>
@@ -81,6 +81,17 @@ <h2><span class="glyphicon glyphicon-pencil"></span>Check a Floating Point Error
 &gt; assert_almost_equal(a, <span class="dt">int</span>(a), places=<span class="dv">2</span>)
 &gt; assert_almost_equal(a, <span class="dt">int</span>(a), delta=<span class="fl">0.003</span>)</code></pre>
 <p>These assertions give much more helpful error messages and have much more powerful features than the simple assert keyword. An even more powerful sibling of the assertion is the <em>exception</em>. We’ll learn about those in the next lesson.</p>
+<blockquote>
+<h2>Key Points</h2>
+<ul>
+<li>Assertions are one line tests embedded in code.</li>
+<li>The <code>assert</code> keyword is used to set an assertion.</li>
+<li>Assertions halt execution if the argument is false.</li>
+<li>Assertions do nothing if the argument is true.</li>
+<li>The <code>nose.tools</code> package provides more informative assertions.</li>
+<li>Assertions are the building blocks of tests.</li>
+</ul>
+</blockquote>
         </div>
       </div>
       </article>

02-assertions.md

@@ -8,8 +8,7 @@ minutes: 10
 > 
 > *   Assertions are one line tests embedded in code.
 > *   Assertions can halt execution if something unexpected happens.
-> *   Assertions are the building block of tests.
-
+> *   Assertions are the building blocks of tests.
 
 Assertions are the simplest type of test. They are used as a tool for bounding 
 acceptable behavior during runtime. The assert keyword in python has the 
@@ -84,3 +83,13 @@ These assertions give much more helpful error messages and have much more
 powerful features than the simple assert keyword. An even more powerful sibling 
 of the assertion is the _exception_. We'll learn about those in the next 
 lesson.
+
+
+> ## Key Points {.keypoints}
+>
+> -   Assertions are one line tests embedded in code.
+> -   The `assert` keyword is used to set an assertion.
+> -   Assertions halt execution if the argument is false.
+> -   Assertions do nothing if the argument is true.
+> -   The `nose.tools` package provides more informative assertions.
+> -   Assertions are the building blocks of tests.

03-exceptions.html

@@ -82,6 +82,14 @@ <h2><span class="glyphicon glyphicon-pencil"></span>What Else Can Go Wrong?</h2>
 </div>
 </section>
 <p>Exceptions have the advantage of being simple to include and powerfully helpful to the user. However, not all behaviors can or should be found with runtime exceptions. Most behaviors should be validated with unit tests.</p>
+<blockquote>
+<h2>Key Points</h2>
+<ul>
+<li>Exceptions are effectively specialized runtime tests</li>
+<li>Exceptions can be caught and handled with a try-except block</li>
+<li>Many built-in Exception types are available</li>
+</ul>
+</blockquote>
         </div>
       </div>
       </article>

03-exceptions.md

@@ -80,3 +80,10 @@ def mean(num_list):
 Exceptions have the advantage of being simple to include and powerfully helpful
 to the user. However, not all behaviors can or should be found with runtime
 exceptions. Most behaviors should be validated with unit tests.
+
+> ## Key Points {.keypoints}
+>
+> -   Exceptions are effectively specialized runtime tests
+> -   Exceptions can be caught and handled with a try-except block
+> -   Many built-in Exception types are available 
+

04-units.html

@@ -136,6 +136,16 @@ <h2><span class="glyphicon glyphicon-pencil"></span>Write a File Full of Tests</
         obs = <span class="dt">int</span>(fhandle.read())
     assert_equal(exp, obd)</code></pre>
 <p>Note that if you have functions in your test module that are simply named <code>setup()</code> and <code>teardown()</code>, each of these are called automatically when the entire test module is loaded in and finished.</p>
+<blockquote>
+<h2>Key Points</h2>
+<ul>
+<li>Functions are the atomistic unit of software.</li>
+<li>Simpler units are easier to test than complex ones.</li>
+<li>A single unit test is a function containing assertions.</li>
+<li>Such a unit test is run just like any other function.</li>
+<li>It may be necessary to set up “fixtures” composing the test environment.</li>
+</ul>
+</blockquote>
         </div>
       </div>
       </article>

04-units.md

@@ -6,11 +6,11 @@ minutes: 10
 ---
 > ## Learning Objectives {.objectives}
 > 
-> *   Understand that functions are the atomistic unit of software.
-> *   Understand that simpler units are easier to test than complex ones.
-> *   Understand how to write a single unit test.
-> *   Understand how to run a single unit test.
-> *   Understand how test fixtures can help write tests.
+> -   Understand that functions are the atomistic unit of software.
+> -   Understand that simpler units are easier to test than complex ones.
+> -   Understand how to write a single unit test.
+> -   Understand how to run a single unit test.
+> -   Understand how test fixtures can help write tests.
 
 Unit tests are so called because they exercise the functionality of the code by
 interrogating individual functions and methods. Fuctions and methods can often
@@ -160,3 +160,12 @@ def test_f():
 Note that if you have functions in your test module that are simply named
 `setup()` and `teardown()`, each of these are called automatically when the
 entire test module is loaded in and finished.
+
+> ## Key Points {.keypoints}
+>
+> -   Functions are the atomistic unit of software.
+> -   Simpler units are easier to test than complex ones.
+> -   A single unit test is a function containing assertions.
+> -   Such a unit test is run just like any other function.
+> -   It may be necessary to set up "fixtures" composing the test environment.
+

05-nose.html

@@ -35,6 +35,7 @@ <h2><span class="glyphicon glyphicon-certificate"></span>Learning Objectives</h2
 <div class="panel-body">
 <ul>
 <li>Understand how to run a test suite using the nose framework</li>
+<li>Understand how to read the output of a nose test suite</li>
 </ul>
 </div>
 </section>
@@ -98,6 +99,17 @@ <h2><span class="glyphicon glyphicon-pencil"></span>Fix The Failing Code</h2>
 </div>
 </section>
 <p>As we write more code, we would write more tests, and <em>nosetests</em> would produce more dots. Each passing test is a small, satisfying reward for having written quality scientific software. Now that you know how to write tests, let’s go into what can go wrong.</p>
+<blockquote>
+<h2>Key Points</h2>
+<ul>
+<li>The <code>nosetests</code> command collects and runs tests starting with <code>Test-</code>, <code>test_</code>, and similar names.</li>
+<li><code>.</code> means the test passed</li>
+<li><code>F</code> means the test failed</li>
+<li><code>E</code> encountered an error</li>
+<li><code>K</code> is a known failure</li>
+<li><code>S</code> is a purposefully skipped test</li>
+</ul>
+</blockquote>
         </div>
       </div>
       </article>

05-nose.md

@@ -6,7 +6,8 @@ minutes: 10
 ---
 > ## Learning Objectives {.objectives}
 > 
-> *   Understand how to run a test suite using the nose framework
+> -   Understand how to run a test suite using the nose framework
+> -   Understand how to read the output of a nose test suite
 
 
 Recall that we created a suite of tests for our mean function.
@@ -106,3 +107,13 @@ As we write more code, we would write more tests, and _nosetests_ would produce
 more dots.  Each passing test is a small, satisfying reward for having written
 quality scientific software. Now that you know how to write tests, let's go
 into what can go wrong.
+
+
+> ## Key Points {.keypoints}
+>
+> -   The `nosetests` command collects and runs tests starting with `Test-`, `test_`, and similar names.
+> -   `.` means the test passed
+> -   `F` means the test failed
+> -   `E` encountered an error
+> -   `K` is a known failure
+> -   `S` is a purposefully skipped test

06-edges.html

@@ -121,6 +121,14 @@ <h2>Write a corner case</h2>
 </blockquote>
 <p>Corner cases can be even trickier to find and debug than edge cases because of their increased complexity. This complexity, however, makes them even more important to explicitly test.</p>
 <p>Whether internal, edge, or corner cases, we have started to build up a classification system for the tests themselves. In the following sections, we will build this system up even more based on the role that the tests have in the software architecture.</p>
+<blockquote>
+<h2>Key Points</h2>
+<ul>
+<li>Functions often fail at the edge of their range of validity</li>
+<li>Edge case tests query the limits of a function’s behavior</li>
+<li>Corner cases are where two edge cases meet</li>
+</ul>
+</blockquote>
         </div>
       </div>
       </article>

06-edges.md

@@ -6,10 +6,10 @@ minutes: 10
 ---
 > ## Learning Objectives {.objectives}
 > 
-> *   Understand that edge  cases are at the limit of the function's behavior
-> *   Write a test for an edge case
-> *   Understand that corner cases are where two edge cases meet
-> *   Write a test for a corner case
+> -   Understand that edge  cases are at the limit of the function's behavior
+> -   Write a test for an edge case
+> -   Understand that corner cases are where two edge cases meet
+> -   Write a test for a corner case
 
 What we saw in the tests for the mean function are called  _interior_ tests.
 The precise points that we tested did not matter. The mean function should have
@@ -155,3 +155,10 @@ Whether internal, edge, or corner cases, we have started to build
 up a classification system for the tests themselves. In the following sections,
 we will build this system up even more based on the role that the tests have
 in the software architecture.
+
+
+> ## Key Points {.keypoints}
+>
+> -   Functions often fail at the edge of their range of validity
+> -   Edge case tests query the limits of a function's behavior
+> -   Corner cases are where two edge cases meet