I love assert

[alister]

On Thu, 27 Nov 2014 01:22:37 -0800, TP wrote:

> On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi
> <peter.cacioppi at gmail.com>
> wrote:
> 
>> 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?
>>
>> As far as I can tell, Python supports assert perfectly well. When run
>> with the optimization flagging, the asserts are truly removed.
>>
>> 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".
>>
>>
> In "Why Most Unit Testing is Waste" by James O Coplien [1] he says on
> page 10:
> 
> "However, as with most unit tests, it's better to make this an assertion
> than to pepper your test framework with such checks."
> 
> page 15:
> 
> "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."
> 
> page 16:
> 
> "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."
> 
> "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."
> 
> And in "Seque" by James O Coplien [2] he is even more emphatic on page
> 17:
> 
> "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."
> 
And as may wiser people than me have already highlighted Assertions can 
be switched off in python which means they cannot be relied upon in 
production code invalidating the authors suggestion that they can 
automate bug reports & "Extend testing into the lifetime of the product"
 

-- 
The state of some commercial Un*x is more unsecure than any Linux box
without a root password...
	-- Bernd Eckenfels