Code correctness, and testing strategies

[Roy Smith]

In article <mailman.1525.1211632496.12834.python-list at python.org>,
 David <wizzardx at gmail.com> wrote:

> Hi list.
> 
> What strategies do you use to ensure correctness of new code?
> 
> Specifically, if you've just written 100 new lines of Python code, then:
> 
> 1) How do you test the new code?
> 2) How do you ensure that the code will work correctly in the future?

There's various philosophies about this (and none of them are specific to 
Python), but I like a process called Test Driven Development (TDD).

In TDD, you invert the order you describe above.  First write the test, 
then write the code to make the tests pass.  What I usually do is write the 
documentation first, then write some tests that assert things the 
documentation says, then write the code.

Python has several testing modules; unittest and doctest come with the 
system, and there's a couple of other third-party modules that have sprung 
up.  I find unittest works well for me and stick with that.

I work in small increments, writing one test at a time, then some code, 
then another test, then some more code, etc.  In fact, I take this to what 
many people might call an extreme.  When I sit down to write a class, the 
first test I write is one that just instantiates an instance of that class 
with no arguments.  Then a write the stub class:

class foo:
   pass

and see that the test works.  If I'm feeling really expansive, I'll write a 
more sophisticated version:

class foo:
   def __init__(self):
      pass

and use that to satisfy my initial test.  Then it's just later, rinse, 
repeat until the class is done, fully documented, and fully tested.

> For (1) I thoroughly (manually) test code as I write it, before
> checking in to version control.

I agree with the idea that it's fully tested before checking it in, but not 
with the manual testing.  In my mind, any test that's not fully automated 
might as well not exist.