Code_J

 Makes me feel le somethng of a code jockey: I now know how

(complex) programs are tested as they evolve. And it involves testing whether

expected values are true or not ie the process is automated so that

anyone running the test can see what is going on...

Python recognizes the assert command as a request for a boolean on an expression.

If true, nothin; if false, an error is thrown.

All well and good, 10 squared is not 101. for a moew complex example, one

might be tempted to just test the program a few times. Again, there is a procedure

within Python, whcih involves expected examples in a test unit.

Here a code unit (with a (sh) extension is a shell command). This allows

the coder to run the test himself.

One can also use unittest which is a python library, (and doesn't use the shell script):

This gets run periodically! 

                                                             *     *     *

The lecture itself contains an interesting instance of an

error from  faulty code in a function. If we define is_prime

as follows, then we raise an error on 25 and 8. 

The issue: the notion of range. which does not include the second 

term as such. For example, range(1, 10) would go from 1 and include 9 

but not 10.

For 25, we are not picking up that the integer 5 squared gives 25, and

thus 25 is not prime. For 8, we end up with range(2, not including2) which

triggers the else condition of True. 

The same situation arises from both the shell code and the unittest. Prime

is just not built-in anywhere.