Keynote - Preventing, Finding, and Fixing Bugs On a Time Budget | Raymond Hettinger @ PyBay2018
Why Hacker News recommends it
HN cites it in Python testing and code quality threads, including his point that 100% coverage proves little.
What it is
Raymond Hettinger's PyBay 2018 keynote on preventing, finding and fixing bugs under a time budget. He covers testing practice, type annotation tradeoffs and the limits of coverage metrics.
Recommended by 1 HN commenters across 1 different months, 2020 to 2022.
What Hacker News said
Recommends Rendello · 2021-03 · on “My Python testing style guide (2017)”
This is a good talk by the core developer Raymond Hettinger [1]. He prefers pytest too. I don't do any crazy testing, but I really like property-based testing with Hypothesis, which is also mentioned. This video isn't Python but it's a great intro to property-based testing [2]. 1. [this video] 2. [LINK]
Cites memco · 2020-12 · on “Python at Scale: Strict Modules”
Yes, they are probably most useful to me for the IDE completions and docs as well. Raymond Hettinger gave at least one talk [1] where he discussed how there are tradeoffs: reasons why you might use them and reasons why you might not. At the end of the day you can pass whatever you want to a function and the only reason to use types if they make your code better—but there are other tools that might be more worth your time in some situations. [1]: [this video]
Cites Rendello · 2021-04 · on “In praise of property-based testing (2019)”
I had a similar experience after watching a Computerphile video with John Hughes, one of the authors of the original propert-based testing tool, QuickCheck [1]. Running hundreds of thousands of unique tests and finding the simplified cases was mind blowing to watch. I loved the video but my first experience with this method was with Python's Hypotheis [2], I haven't used it a ton but it's great for finding parsing errors. In the words of Python core developer Raymond Hettinger: > It's not quite fuzzing, but it hits it with the kind of test cases that a good QA engineer would typically come up with, and it does it in automated fashion. 1. [LINK] 2. [LINK] 3. [this video]
Cites TrickardRixx · 2022-12 · on “Boring Python: Code Quality”
Please see Raymond Hettinger's keynote on efficiently handling bugs[0]. He makes the case that static type checking is a boon for Python except for in specific programs that make extensive use of covariant and/or contravariant types. [0] [this video]
Cites hbrn · 2022-12 · on “Boring Python: Code Quality”
My examples are just personal anecdotes, you can dismiss them by saying "our team won't make the same mistake". If your goal is 100% coverage then it will turn testing into ritual and only give you the illusion of quality. Instead of testing inputs and edge cases, you will focus on testing lines of code. There's a good illustration of uselessness of 100% coverage in one of Raymond Hettinger talks: [this video] > I use testing as a tool to be sure we ship quality code I suspect we have different definitions of quality, and your might include testing, so I doubt I will be able to convince you.