Friday finking: TDD and EAFP

[DL Neil]

On 2/11/19 4:32 PM, boB Stepp wrote:
> On Fri, Nov 1, 2019 at 12:42 AM DL Neil via Python-list
> <python-list at python.org> wrote:
>>
>> Is the practice of TDD fundamentally, if not philosophically, somewhat
>> contrary to Python's EAFP approach?
> [...]
>> In encouraging my mind to think about testing the code, I find myself
>> searching for edge-cases, and attempting to anticipate the unusual.
>> Accordingly to the gospel of TDD: so far, so good.
>>
>> The 'problem' is, that it puts my mind onto LBYL-rails before the
>> Python-coding train (of thought) has even left the station. It then
>> seems natural to start putting a bunch of if-then-else's up-front and
>> before the 'main line' of code.
>>
>> Does TDD bend your mind in this (apparently) non-Pythonic fashion?
>> Have you developed an answer?
>> (other than: "@dn is 'nuts'*", which is not worthy of debate)
> 
> As the pros have yet to chime in, I will attempt to add my amateurish

Thanks!

Because I have several rôles and spend only a proportion of my time 
actually coding, I fear that I should claim a less-than professional 
status. No matter.

It's an interesting comment though: I've been wondering if many 'Python 
pros' actually use TDD - few of the people I work alongside (in 
programmer-mode) do. Thus there are TDD 'evangelists', loud detractors, 
and most 'in the middle' or simply not wanting to engage in such a debate.

Perhaps 'Python pros' don't use TDD. Which in-and-of-itself, somewhat 
answers the question!


> thoughts.  In my on again/off again efforts to self-study Python,
> sound software construction practices, etc., I have been endeavoring
> to adopt a TDD approach.  I find that trying to do this forces upon me
> more clarity of thought which (hopefully) results in more expressive,
> simpler and understandable code.  As I often find my initial efforts
> at writing tests murky and hard to understand, I (eventually) realize
> that the associated code I'm trying to test, which seemed so clear
> when I first wrote it, is hard to test.  So I refactor/simplify the
> code, it becomes easier to write sensible test code, etc.  It may just
> be me and my lack of experience, but I find this circular process
> ultimately leads to more Pythonic results -- easier to understand code
> that (I hope) others can easily read and understand.
> 
> Though I am sure I am stating the obvious, instead of just thinking
> about edge cases, I like to have at least one test that proves that
> what I normally expect to get is, in fact, gotten.  I often
> embarrassingly find myself caught in some sort of simple logic error
> that this type of test will catch, especially later if I am
> refactoring my code in the direction I am trying to coerce it to go
> for the end product.
> 
> I am probably far from thinking/coding in a proper Pythonic fashion,
> but the TDD back-and-forth process seems to get me closer to being
> Pythonic.

Yes, normally the first test(s) (eg for some method/function) would be 
the desired behavior(s) - testing that we will enjoy the expected 
benefits of the actual code/that the code does what it should. 
Thereafter it become a case of ensuring there's nothing 'else' or 
undesired... ie there's no point in worrying about (say) a "divide by 
zero" condition, if the formula doesn't already prove with valid data!

Unlike yourself - and probably the circular approach described by most 
TDD advocates, my approach has been to write the method's (probably) 
signature and docstring + pass first. Then to transfer those objectives 
to Pytest code, where I write test-after-test - because I'm in the mode 
of thinking about 'what-ifs'.

Once I'm reasonably satisfied that I've covered the specs, then it 
becomes time to write the code - during which I do follow a circular 
fashion - satisfy the first test, then satisfy the second... always 
ensuring that subsequent refactoring doesn't abrogate an earlier 'pass'.


Hence the observation that an (attempt at an) exhaustive examination of 
the spec is rather LBYL; whereas the circular code-and-test might be 
more Pythonic if it were more EAFP, but that starting with a somewhat 
LBYL approach might tend to keep one thinking that way...

(of course it is never quite a clean-cut the idealised two-stage 
description (above). There are always considerations which occur to me 
'later', and changes/improvements to the spec which arise as the team 
'burns down' the sprint...)
-- 
Regards =dn