Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
From: Marco Buttu <marco.buttu@gmail.com>
Date: Thu, 18 Jun 2015 11:00:57 +0200
Reply-To: mbuttu@oa-cagliari.inaf.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Classic OOP in Python
References: <23b2fae3-91d5-486b-9898-78b34bee486f@googlegroups.com> <16dc8c92-50e3-4fc8-ae25-cbc5b13e8971@googlegroups.com> <87eglaqdca.fsf@elektro.pacujo.net> <6944ae86-86eb-4a9b-be05-21d0be7bb206@googlegroups.com>
In-Reply-To: <6944ae86-86eb-4a9b-be05-21d0be7bb206@googlegroups.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.589.1434620701.13271.python-list@python.org>
Lines: 40
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python: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