Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #92772 > unrolled thread

Classic OOP in Python

Back to article view | Back to comp.lang.python

Contents

  Classic OOP in Python "Jason P." <suscricions@gmail.com> - 2015-06-17 12:21 -0700
    Re: Classic OOP in Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-17 14:38 -0500
    Re: Classic OOP in Python Ned Batchelder <ned@nedbatchelder.com> - 2015-06-17 12:44 -0700
      Re: Classic OOP in Python Marko Rauhamaa <marko@pacujo.net> - 2015-06-17 23:39 +0300
        Re: Classic OOP in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-17 22:07 +0100
        Re: Classic OOP in Python Ned Batchelder <ned@nedbatchelder.com> - 2015-06-17 14:14 -0700
          Re: Classic OOP in Python Laura Creighton <lac@openend.se> - 2015-06-18 00:33 +0200
            Re: Classic OOP in Python Ned Batchelder <ned@nedbatchelder.com> - 2015-06-17 15:55 -0700
          Re: Classic OOP in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-18 11:50 +0100
          Re: Classic OOP in Python Laura Creighton <lac@openend.se> - 2015-06-19 01:01 +0200
          Re: Classic OOP in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-20 23:52 +0100
          Re: Classic OOP in Python Laura Creighton <lac@openend.se> - 2015-06-21 10:26 +0200
        Re: Classic OOP in Python sohcahtoa82@gmail.com - 2015-06-17 14:33 -0700
          Re: Classic OOP in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-17 22:49 +0100
          Re: Classic OOP in Python Laura Creighton <lac@openend.se> - 2015-06-18 00:22 +0200
          Re: Classic OOP in Python Marco Buttu <marco.buttu@gmail.com> - 2015-06-18 11:00 +0200
        Re: Classic OOP in Python Laura Creighton <lac@openend.se> - 2015-06-18 00:09 +0200
        Re: Classic OOP in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-17 23:27 +0100
        Re: Classic OOP in Python Steven D'Aprano <steve@pearwood.info> - 2015-06-18 08:58 +1000
          Re: Classic OOP in Python Cousin Stanley <cousinstanley@gmail.com> - 2015-06-18 08:10 -0700
        Re: Classic OOP in Python Terry Reedy <tjreedy@udel.edu> - 2015-06-17 19:46 -0400
        Re: Classic OOP in Python Chris Angelico <rosuav@gmail.com> - 2015-06-18 10:07 +1000
        Re: Classic OOP in Python "Jason P." <suscricions@gmail.com> - 2015-06-18 04:24 -0700
      Re: Classic OOP in Python "Jason P." <suscricions@gmail.com> - 2015-06-18 04:21 -0700
        Re: Classic OOP in Python Ned Batchelder <ned@nedbatchelder.com> - 2015-06-18 04:54 -0700
      Re: Classic OOP in Python "Jason P." <suscricions@gmail.com> - 2015-06-18 04:22 -0700
    Re: Classic OOP in Python sohcahtoa82@gmail.com - 2015-06-17 14:16 -0700
      Re: Classic OOP in Python Fabien <fabien.maussion@gmail.com> - 2015-06-18 13:03 +0200
        Re: Classic OOP in Python Marko Rauhamaa <marko@pacujo.net> - 2015-06-18 14:25 +0300
        Re: Classic OOP in Python Chris Angelico <rosuav@gmail.com> - 2015-06-18 21:43 +1000

Page 1 of 2  [1] 2  Next page →

#92772 — Classic OOP in Python

Hello Python community.

I come from a classic background in what refers to OOP. Mostly Java and PHP (> 5.3). I'm used to abstract classes, interfaces, access modifiers and so on.

Don't get me wrong. I know that despite the differences Python is fully object oriented. My point is, do you know any book or resource that explains in deep the pythonic way of doing OOP?

For example, I'm gonna try to develop a modest application from ground up using TDD. If it had been done in Java for instance, I would made extensive use of interfaces to define the boundaries of my system. How would I do something like that in Python?


Many thanks!

[toc] | [next] | [standalone]

#92774

On Wed, Jun 17, 2015 at 2:21 PM, Jason P. <suscricions@gmail.com> wrote:
> I'm gonna try to develop a modest application from ground up using
> TDD. If it had been done in Java for instance, I would made
> extensive use of interfaces to define the boundaries of my
> system. How would I do something like that in Python?

Maybe start here:

http://stackoverflow.com/questions/2124190/how-do-i-implement-interfaces-in-python

and see if abstract base classes will be sufficient.  (I wouldn't
know. I've never used Java or PHP.)

More generally, you might try search the web for "interfaces in
python".  The above just seemed to be the most relevant response to
me.

Skip

[toc] | [prev] | [next] | [standalone]

#92775

On Wednesday, June 17, 2015 at 3:21:32 PM UTC-4, Jason P. wrote:
> Hello Python community.
> 
> I come from a classic background in what refers to OOP. Mostly Java and PHP (> 5.3). I'm used to abstract classes, interfaces, access modifiers and so on.
> 
> Don't get me wrong. I know that despite the differences Python is fully object oriented. My point is, do you know any book or resource that explains in deep the pythonic way of doing OOP?
> 
> For example, I'm gonna try to develop a modest application from ground up using TDD. If it had been done in Java for instance, I would made extensive use of interfaces to define the boundaries of my system. How would I do something like that in Python?
> 
> 
> Many thanks!

What other languages do with interfaces, Python does with duck-typing. You
can build something like interfaces in Python, but many people don't bother.

I don't know if your project will be web-based, but here is an entire book
about developing Python web sites with a TDD approach:

http://www.obeythetestinggoat.com/

(Don't mind the unusual domain name, it's a bit of an inside joke...)

TDD and interfaces are separate concepts, and I'm not sure they even
intersect.  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.

--Ned.

[toc] | [prev] | [next] | [standalone]

#92777

Ned Batchelder <ned@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.

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.


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.


Marko

[toc] | [prev] | [next] | [standalone]

#92779

On 17/06/2015 21:39, Marko Rauhamaa wrote:
> Ned Batchelder <ned@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.
>
> 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.
>
>
> 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.
>
>
> Marko
>

Awesome, one of the funniest things I've read in years.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#92780

On Wednesday, June 17, 2015 at 4:39:31 PM UTC-4, Marko Rauhamaa wrote:
> 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.

The true TDD acolytes advocate a very idiosyncratic workflow, it's true.
I don't do this, but I also don't consider myself a TDD person. I value
tests a great deal, and put a lot of effort into them, but I don't write
trivial functions to get my tests to pass and then go back to change them.

But people whose opinion I value do advocate that, and it's possible that
in time I will understand their methods and use them myself.  Stranger
things have happened...

--Ned.

[toc] | [prev] | [next] | [standalone]

#92788

In a message of Wed, 17 Jun 2015 14:14:34 -0700, Ned Batchelder writes:

>The true TDD acolytes advocate a very idiosyncratic workflow, it's true.
>I don't do this, but I also don't consider myself a TDD person. I value
>tests a great deal, and put a lot of effort into them, but I don't write
>trivial functions to get my tests to pass and then go back to change them.

Grrr.  I am a true TDD acolyte.  And I don't do that either.

>But people whose opinion I value do advocate that, and it's possible that
>in time I will understand their methods and use them myself.  Stranger
>things have happened...
>
>--Ned.

Seriously?  Oh you humble man.

I have convinced a huge number of people who used to have that sort of
dogma that the reason they advocated such baby steps is that they
didn't have a good coverage tool. ***grin***

TDD is supposed to make you brave, not cowards, and it's
Ned's most excellent tool
http://nedbatchelder.com/code/coverage/
that I recommend to TDD dogmatic cowards.

Even if you don't want to use TTD, you will enjoy Ned's tool.  It's GREAT.
Thank you, Ned.

Laura

[toc] | [prev] | [next] | [standalone]

#92790

On Wednesday, June 17, 2015 at 6:34:23 PM UTC-4, Laura Creighton wrote:
> TDD is supposed to make you brave, not cowards, and it's
> Ned's most excellent tool
> http://nedbatchelder.com/code/coverage/
> that I recommend to TDD dogmatic cowards.
> 
> Even if you don't want to use TTD, you will enjoy Ned's tool.  It's GREAT.
> Thank you, Ned.
> 
> Laura

So much for humility I guess.  *blush*.  Thanks!

--Ned.

[toc] | [prev] | [next] | [standalone]

#92815

On 17/06/2015 23:33, Laura Creighton wrote:
> In a message of Wed, 17 Jun 2015 14:14:34 -0700, Ned Batchelder writes:
>
>
> TDD is supposed to make you brave, not cowards, and it's
> Ned's most excellent tool
> http://nedbatchelder.com/code/coverage/
> that I recommend to TDD dogmatic cowards.
>
> Even if you don't want to use TTD, you will enjoy Ned's tool.  It's GREAT.
> Thank you, Ned.
>
> Laura
>

Throw in http://clonedigger.sourceforge.net/ as well and you've a really 
awesome combination.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#92859

In a message of Thu, 18 Jun 2015 11:50:28 +0100, Mark Lawrence writes:
>Throw in http://clonedigger.sourceforge.net/ as well and you've a really 
>awesome combination.
>
>Mark Lawrence
>

I didn't know about that one.
Hey thank you, Mark.  Looks great.

It needs its own entry in
https://wiki.python.org/moin/PythonTestingToolsTaxonomy

You add it, or me?

Laura

[toc] | [prev] | [next] | [standalone]

#92920

On 19/06/2015 00:01, Laura Creighton wrote:
> In a message of Thu, 18 Jun 2015 11:50:28 +0100, Mark Lawrence writes:
>> Throw in http://clonedigger.sourceforge.net/ as well and you've a really
>> awesome combination.
>>
>> Mark Lawrence
>>
>
> I didn't know about that one.
> Hey thank you, Mark.  Looks great.
>
> It needs its own entry in
> https://wiki.python.org/moin/PythonTestingToolsTaxonomy
>
> You add it, or me?
>
> Laura
>

Thanks all the same but I'll leave it to you, as I suspect I'd be my 
usual combination of headless chicken and bull in a china shop if let 
loose on a wiki :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#92936

Ah, turns out there was an entry.  I updated it.

Laura

[toc] | [prev] | [next] | [standalone]

#92782

On Wednesday, June 17, 2015 at 1:39:31 PM UTC-7, Marko Rauhamaa wrote:
> Ned Batchelder <ned@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.
> 
> 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.
> 
> 
> 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.
> 
> 
> Marko

I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it.  We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back.  It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code.

As an in-class exercise, we had to write an implementation of Conway's Game of Life.  I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs.  Meanwhile, the people doing TDD the "right" way didn't even have a complete program after over an hour.

The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring.

IMO, that kind of TTD is an utter waste of time.

[toc] | [prev] | [next] | [standalone]

#92783

On 17/06/2015 22:33, sohcahtoa82@gmail.com wrote:
> On Wednesday, June 17, 2015 at 1:39:31 PM UTC-7, Marko Rauhamaa wrote:
>> Ned Batchelder <ned@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.
>>
>> 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.
>>
>>
>> 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.
>>
>>
>> Marko
>
> I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it.  We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back.  It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code.
>
> As an in-class exercise, we had to write an implementation of Conway's Game of Life.  I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs.  Meanwhile, the people doing TDD the "right" way didn't even have a complete program after over an hour.
>
> The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring.
>
> IMO, that kind of TTD is an utter waste of time.
>

Couldn't agree with you more.  To once again quote my favourite part of 
the Zen of Python, "practicality beats purity".

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#92786

In a message of Wed, 17 Jun 2015 14:33:43 -0700, sohcahtoa82@gmail.com writes:

>I had a Java class where we had to learn TDD, and that's the way TDD
>was taught to us, and I hated it.  We watched a video of this guy
>explaining TDD with a hat that was red on the front and green on the
>back.  It involved writing a simple failing unit test, then write
>code to fix it, then refactor the tests and/or code.  As an in-class
>exercise, we had to write an implementation of Conway's Game of Life.
>I threw TDD out the window and just wrote the damn program in under
>15 minutes, then another 10 minutes to write unit tests that tested
>every possible code branch and several invalid inputs.  Meanwhile,
>the people doing TDD the "right" way didn't even have a complete
>program after over an hour.  The brand of TTD we were taught would
>end up multiplying development time by at least a factor of 3, and by
>the time you were done, at least 75% of the tests you had written
>will have been removed due to rampant refactoring.  IMO, that kind of
>TTD is an utter waste of time.

I'd hate that too.  But that's not the TDD I know, or teach.  Please
don't write off TDD as a result of this experience.

Laura

[toc] | [prev] | [next] | [standalone]

#92811

On 17/06/2015 23:33, sohcahtoa82@gmail.com wrote:
> I had a Java class where we had to learn TDD, and that's the way TDD was taught to us, and I hated it. We watched a video of this guy explaining TDD with a hat that was red on the front and green on the back.  It involved writing a simple failing unit test, then write code to fix it, then refactor the tests and/or code.

I do not think it is important that the test fails before writing the 
code, but for sure it is really wise to ensure every test fails at least 
once. If I wrote a test and it has never failed before, then I always 
change something in the test itself, in order to have an expected 
failure. And sometimes the expected failures make me better understand 
the behavior of the code.

> As an in-class exercise, we had to write an implementation of Conway's Game of Life.  I threw TDD out the window and just wrote the damn program in under 15 minutes, then another 10 minutes to write unit tests that tested every possible code branch and several invalid inputs.  Meanwhile, the people doing TDD the "right" way didn't even have a complete program after over an hour.
>
> The brand of TTD we were taught would end up multiplying development time by at least a factor of 3, and by the time you were done, at least 75% of the tests you had written will have been removed due to rampant refactoring.
>
> IMO, that kind of TTD is an utter waste of time.

I think TDD helps a lot to design the code to be "testable" as much as 
possible. I believe good and experienced programmers could think in 
advance the way to write testable code, without be driven by tests. 
However, I also think that the bigger part of programmers, as me, do not 
have this ability. That's the case TDD comes in handy helping us to 
write testable code.

In case of bug fixing, I think also experienced and good programmers 
that do not believe in TDD should always write the tests in advance, for 
instance because:

* it is really the better way to understand the problem and point to it
* chances are that you will not write a test after fixing the bug, i.e. 
because you may have other priorities, so you will miss a regression test


-- 
Marco Buttu

INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email: mbuttu@oa-cagliari.inaf.it

[toc] | [prev] | [next] | [standalone]

#92785

In a message of Wed, 17 Jun 2015 23:39:17 +0300, Marko Rauhamaa writes:
>Ned Batchelder <ned@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

[toc] | [prev] | [next] | [standalone]

#92787

On 17/06/2015 23:09, Laura Creighton wrote:
>
> 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.
>

Strange, I see no such evidence, just a person who lives firmly in cloud 
cuckoo land.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#92791

On Thu, 18 Jun 2015 06:39 am, Marko Rauhamaa wrote:

> Ned Batchelder <ned@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.
> 
> 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.

You still need requirements and a design. Otherwise how do you know what
tests you need to write?


> 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.

That's certainly the more pedantic approach of TDD proponents. But frankly I
expect that outside of TDD tutorials, nobody *really* starts off that small
in practice. I know I don't.

I would start with this function, and a separate test suite:


# === application.py ===
def bracket(s):
    """Return string s bracketed in parentheses.

    >>> bracket("Hello")
    '(Hello)'

    """
    return "(%s)" % s


# === test_application.py ===
import application

import doctest
import unittest

def load_tests(loader, tests, ignore):
    tests.addTests(doctest.DocTestSuite())
    tests.addTests(doctest.DocTestSuite(application))
    return tests


if __name__ == '__main__':
    unittest.main()


Then call 

python test_application.py


to run the tests. Or even skip the test suite and just call 

python -m doctest application.py


And from there, I would build up extra doc tests and unit tests as needed.

The point is, I don't believe that there is any *necessity* to write
deliberately failing tests for *trivial* functions that are only one or two
lines. You can practically see that the function is correct without even a
test. Deliberately making it fail has only one advantage:

* Getting you used to failing tests and learning that they aren't in and of
themselves a bad thing or something to be ashamed of;

* Instilling the discipline to actually write tests.

Er, that's two advantages.

But really, in practice, how many trivial one liner functions do you end up
writing, as a percentage of your entire application? Unless the app is
pretty simple, chances are that percentage is very small.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#92833

> ....
> python -m doctest application.py
> 
> And from there, I would build up extra doc tests
> ....

An extra doc test .... 

  that fails ....


#!/usr/bin/env python

"""
    NewsGroup .... comp.lang.python 
    Subject ...... Classic OOP in Python
    Date ......... 2015-06-17
    Post_By ...... Steven D'Aprano
    Edit_By ...... Stanley C. Kitching
"""

def bracket( s ) :

    """Return string s bracketed in parentheses.

    >>> bracket( "Hello" )
    '(Hello)'

    >>> bracket( "Yo Mama is a Perl Monkey" )
    '(Yo Mama is a Java Monkey')

    """

    return "(%s)" % s


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web