27K views · Sep 21, 2018 · 40:01 · 1 HN recommender · 5 mentions · discussed 2020–2022
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.
Why Hacker News points people here: HN cites it in Python testing and code quality threads, including his point that 100% coverage proves little.
“This is a good talk by the core developer Raymond Hettinger [1].”HN comment, 2021
“This is a good talk by the core developer Raymond Hettinger [1].”
Good talk on testing by a Python core developer
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
“Raymond Hettinger gave at least one talk [1] where he discussed how there are tradeoffs”
Hettinger discusses tradeoffs of using type annotations
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
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
“Please see Raymond Hettinger's keynote on efficiently handling bugs[0].”
Hettinger's case for static type checking in Python
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
“There's a good illustration of uselessness of 100% coverage in one of Raymond Hettinger talks”
Illustrates the uselessness of 100% test coverage
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.
