You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>Sometimes it is not obvious what type of exception to catch and an easy solution seems to be to catch <em>any</em> exception with <code>except Exception</code>. Why is this not a good idea?</p>
248
248
</div>
249
249
</section>
250
250
<sectionclass="challenge panel panel-success">
251
251
<divclass="panel-heading">
252
-
<h2id="checking-or-trying"><spanclass="glyphicon glyphicon-pencil"></span>Checking or trying?</h2>
252
+
<h2><spanclass="glyphicon glyphicon-pencil"></span>Checking or trying?</h2>
253
253
</div>
254
254
<divclass="panel-body">
255
255
<p>What is the advantage of using <code>try</code>/<code>except</code> over an explicit type check? Compare these two functions that return the minimum and maximum as a tuple:</p>
<li>We are still not sure the result is actually correct! We cannot test the correctness of the solution in the function itself, because for that we’d need a solution for all possible inputs – if we already had this, we’d not need the function in the first place…</li>
47
47
<li>We do not know whether the code works before we actually run it. The assertions might guard us against incorrect results (which is already great) but it would be better to have some more confidence in our code before we, say, run it overnight to analyse our data.</li>
48
48
</ol>
49
-
<p>This is where unit tests come in. Unit tests are so called because they exercise the functionality of the code by interrogating individual functions and methods. Fuctions and methods can often be considered the atomic units of software because they are indivisble. However, what is considered to be the smallest code <em>unit</em> is subjective. The body of a function can be long or short, and shorter functions are arguably more unit-like than long ones.</p>
49
+
<p>This is where unit tests come in. Unit tests are so called because they exercise the functionality of the code by interrogating individual functions and methods. Functions and methods can often be considered the atomic units of software because they are indivisible. However, what is considered to be the smallest code <em>unit</em> is subjective. The body of a function can be long or short, and shorter functions are arguably more unit-like than long ones.</p>
50
50
<p>Thus what reasonably constitutes a code unit typically varies from project to project and language to language. A good guideline is that if the code cannot be made any simpler logically (you cannot split apart the addition operator) or practically (a function is self-contained and well defined), then it is a unit.</p>
51
51
<asideclass="callout panel panel-info">
52
52
<divclass="panel-heading">
53
-
<h2id="functions-are-like-paragraphs"><spanclass="glyphicon glyphicon-pushpin"></span>Functions are Like Paragraphs</h2>
53
+
<h2><spanclass="glyphicon glyphicon-pushpin"></span>Functions are Like Paragraphs</h2>
54
54
</div>
55
55
<divclass="panel-body">
56
-
<p>Recall that humans can only hold a few ideas in our heads at once. Paragraphs in books, for example, become unwieldy after a few lines. Functions, generaly, shouldn’t be longer than paragraphs. Robert C. Martin, the author of “Clean Code” said : “The first rule of functions is that <em>they should be small</em>. The second rule of functions is that <em>they should be smaller than that</em>.”</p>
56
+
<p>Recall that humans can only hold a few ideas in our heads at once. Paragraphs in books, for example, become unwieldy after a few lines. Functions, generally, shouldn’t be longer than paragraphs. Robert C. Martin, the author of “Clean Code” said : “The first rule of functions is that <em>they should be small</em>. The second rule of functions is that <em>they should be smaller than that</em>.”</p>
57
57
</div>
58
58
</aside>
59
59
<p>The desire to unit test code often has the effect of encouraging both the code and the tests to be as small, well-defined, and modular as possible.<br/>In Python, unit tests typically take the form of test functions that call and make assertions about methods and functions in the code base. To run these test functions, a test framework is often required to collect them together. For now, we’ll write some tests for the rescale function and simply run them individually to see whether they fail. In the next session, we’ll use a test framework to collect and run them.</p>
@@ -69,7 +69,7 @@ <h2 id="unit-tests-are-just-functions">Unit Tests Are Just Functions</h2>
69
69
<p>When writing such unit tests, special care should be taken to test <em>edge cases</em>, i.e. what happens at the boundaries of the input space. A function may assume a positive value for one of its argument, but what happens if it is 0? Or negative? Another typical edge case is an empty list or array as an argument. Often you will think about those cases only when writing the tests which then forces you to make a decision about how to handle the edge case (which you should then of course include in your function documentation). For example, what should <code>rescale</code> do for an empty array, should it raise an error or should it maybe rather return another empty array?</p>
70
70
<sectionclass="challenge panel panel-success">
71
71
<divclass="panel-heading">
72
-
<h2id="write-a-file-full-of-tests"><spanclass="glyphicon glyphicon-pencil"></span>Write a File Full of Tests</h2>
72
+
<h2><spanclass="glyphicon glyphicon-pencil"></span>Write a File Full of Tests</h2>
0 commit comments