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@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
--
https://mail.python.org/mailman/listinfo/python-list
