In article <[EMAIL PROTECTED]>,
David <[EMAIL PROTECTED]> 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.
--
http://mail.python.org/mailman/listinfo/python-list
