Friday finking: TDD and EAFP

[Barry Scott]

> On 1 Nov 2019, at 05:40, 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?
> 
> 
> TDD = Test-Driven Development
> EAFP = it's easier to ask forgiveness than permission
> * WebRefs as footnote
> 
> 
> The practice of TDD* is that one writes test routines to prove a unit of code, eg method or function; BEFORE actually writing said function.
> 
> The rationale is that TDD encourages proper identification and consideration of the routine's specification, and attempts to ensure that exceptions and "edge-cases" are not quietly forgotten.
> (in a broad-brush, nut-shell)

The practice of creating software is a social activity where those involved
have foibles. Managing all the social interactions and foibles is what
the methodologies are trying to help with. Any methodology that is easier
to follow then avoid will tend to be taken up and provide a benefit.

We all know that tests are a must have, but often those tests that we all
know are a must have do not get written. It can often seem like a chore,
after all the code works right?

By starting with the tests the social engineering means that you make having
the tests the easy part of the process.

Methodologies like Agile address other foibles. Given a far off dead line
the tendency is to delay getting the bulk of the work done until at the last
moment.

So is TDD contrary to EAFP? Not as such its two sorts of social engineering.
TDD helps get the tests, EAPF give permission to take risks, necessary to
innovate.

Barry




> 
> However, I quite possibly like yourself, come from a time-before - before TDD, and before Python. So, have had to not only learn these things, but sometimes, un-learn points and habits (if not vices). Accordingly, I came (quite unknowing of the term, or that there might be an alternative) from the world of LBYL* (look before you leap).
> 
> In other words, before you do anything with some data, check that it is what you think it is. Whereas in Python we "try" by assuming everything is compos-mentis* and handle the "except" when things are not how we'd like.
> 
> That adaptation was not too difficult. After all, aren't programmers an optimistic bunch - I mean, I *never* introduce bugs into *my* code! Do you?
> 
> Which brings us to TDD. Here we assume the likelihood of bugs, as-if (cue: manic giggling); and code a bunch of tests first - in an attempt to prove that the code is up-to-spec.
> 
> 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)
> 
> 
> WebRefs:
> https://duckduckgo.com/?q=TDD&ia=web
> https://devblogs.microsoft.com/python/idiomatic-python-eafp-versus-lbyl/
> https://docs.python.org/3/glossary.html#term-eafp
> but: https://mail.python.org/pipermail/python-dev/2014-March/133118.html
> https://docs.python.org/3/glossary.html#term-lbyl
> Latin/legal term "compos mentis" https://www.thefreedictionary.com/compos+mentis
> English slang term "nuts": https://www.thefreedictionary.com/nuts
> -- 
> Regards,
> =dn
> -- 
> https://mail.python.org/mailman/listinfo/python-list
>