<div dir="ltr"><div class="gmail_default" style="font-size:small"></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi <span dir="ltr"><<a href="mailto:peter.cacioppi@gmail.com" target="_blank">peter.cacioppi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?<br>
<br>
As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.<br>
<br>
I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".<br>
<span class=""></span></blockquote><div><br><div class="gmail_default" style="font-size:small;display:inline">In "Why Most Unit Testing is Waste" by James O Coplien [1] he says on page 10:<br><br>"However, as with most unit tests, it’s better to make this an assertion than to pepper your test framework with such checks."<br><br>page 15:<br><br>"When I look at most unit tests — especially those written with JUnit — they are assertions in disguise. When I write a great piece of software I sprinkle it with assertions that describe promises that I expect the callers of my functions to live up to, as well as promises that function makes to its clients. Those assertions evolve in the same artefact as the rest of my code."<br><br>page 16:<br><br>"An even more professional approach is to leave the assertions in the code when you ship, and to automatically file a bug report on behalf of the end user and perhaps to try to re-start the application every time an assertion fails."<br><br>"Turn unit tests into assertions. Use them to feed your fault-tolerance architecture on high-availability systems. This solves the problem of maintaining a lot of extra software modules that assess execution and check for correct behavior; that’s one half of a unit test. The other half is the driver that executes the code: count on your stress tests, integration tests, and system tests to do that."<br><br>And in "Seque" by James O Coplien [2] he is even more emphatic on page 17:<br><br>"This argumentation, of course, is just an alternative justification for the use of assertions in the code, as we already introduced in Chapter 1. Assertions are powerful unit-level guards that beat most unit tests in two ways. First, each one can do the job of a large number (conceivably, infinite) of scenario-based unit tests that compare computational results to an oracle. Second, they extend the run time of the test over a much wider range of contexts and detailed scenario variants by extending the test into the lifetime of the product."<br><br>[1] <a style="color:#3366ff" class="linkificator-ext" href="http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf" title="Linkificator: http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf">http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf</a><br><br>[2] <a style="color:#3366ff" class="linkificator-ext" href="http://www.rbcs-us.com/documents/Segue.pdf" title="Linkificator: http://www.rbcs-us.com/documents/Segue.pdf">http://www.rbcs-us.com/documents/Segue.pdf</a><br><br></div></div></div></div></div>