Classic OOP in Python

[Laura Creighton]

In a message of Wed, 17 Jun 2015 23:39:17 +0300, Marko Rauhamaa writes:
>Ned Batchelder <ned at nedbatchelder.com>:
>
>> TDD is about writing tests as a way to design the best system, and
>> putting testing at the center of your development workflow. It works
>> great with Python even without interfaces.
>
>I wonder how great it really is. Testing is important, that's for sure,
>but to make it a dogmatic starting point of development is not that
>convincing.

Try it and see.

>The way it was explained to me was that in TDD you actually don't write
>code to any requirements or design: you simply do the least to pass the
>tests. Thus, say you need to write a program that inputs a string and
>outputs the same string surrounded by parentheses (the requirement), the
>starting point might be this test case:
>
>   - run the program
>   - give it the word "hello" as input
>   - check that the program prints out "(hello)"
>
>The right TDD thing would be to satisfy the test with this program:
>
>   input()
>   print("(hello)")
>
>That *ought* to be the first version of the program until further test
>cases are added that invalidate it.

You have been talking to people who are beginners at TDD.  They have
been taught some hard and fast rules to keep them from the problem
of over-designing.  Or you may have been taking to fools.

Both beginners and fools badly want to replace the wisdom that they
don't have in their heads with some rules from somebody else's head.
Beginners can work this way, and develop wisdom over time.  Fools,
pretty much by definition cannot.

The way I usually work is to take a list of requirements from some
user(s) and turn them into test cases.  And then the job of design
is to get from where I am 'have no code' to I can begin satisfying
some of these requirements.

Just because 
>   input()
>   print("(hello)")

would satisfy the test you wrote doesn't mean it is a correct TTD thing
to do -- because it doesn't get you any closer to solving the real
problem your design is supposed to do.

This doesn't mean that you need to write your tests in a more
complicated way to prevent smart-asses from doing stuff like the
above.  It means that your tests should make you get closer to your
goal.  You will have to make a bridge of tests to get from 'I
have nothing' to the first user supplied test you need to meet,
but you do have a destination, and you need to go there.

I teach a bunch of 11 year olds to program in python using TTD and
pytest.  A good number of them end up writing tests to test that
the python standard library works the way they expect it to.  In some
sense, this is a waste of their time, but I resist the urge to
tell them so.  They are developing wisdom and understanding of the
standard library, and confidence.  When they are wiser, they can
delete some of these superfluous tests, but as for now, these tests
are a measure of their growing understanding.  If you have
oversimplified what you have been told, then it may be that you have
missed this 'and I learned something here' bit they were telling you
about, even if you think that they ought to have known it all along.

Teaching design is hard.

Teaching design to smart-asses who don't want to learn design at all
but want some ruleset to be 'better than design' is impossible.

But teaching design using TTD as a tool for design.  Well, that is
_wonderful_.


>Another interesting ism I have read about is the idea that the starting
>point of any software project should be the user manual. The developers
>should then go and build the product that fits the manual.

Unless the manual is bloody short, in which case it is a series of
acceptance tests -- this is a rotten idea.  The marketing department
makes the user manual, the engineers implement it, and the users get
screwed as they get, not what they want, but what somebody in
marketing, or (only slightly better) engineering thinks that they
wanted, or ought to want.

If at all possible, you want the starting point of your software
development to be a conversation between the people who are going to
write the thing and the people who are going to use the thing, with
particular attention to what the users are using now, and why they
want something else instead of just more of the same.

>
>
>Marko

ps -- Marko, we have ample evidence that you are an extremely clever
person.  But the purpose of TTD is not to make clever code, but
wise code.  TTD in the hands of a fool will never produce that.
But how else do you have to check that your design, while clever
isn't _too damn clever_?  Aren't you plagued with that problem?  I am
and TDD is the best thing I ever learned to keep that tendancy I have
to write too clever code in check.

Laura again