Summary Michael Foord has been working on building and testing software in Python for over a decade. One of his most notable and widely used contributions to the community is the Mock library, which has been incorporated into the standard library. In this episode he explains how he got involved in the community, why testing has been such a strong focus throughout his career, the uses and hazards of mocked objects, and how he is transitioning to freelancing full time. Preface Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great. When you’re ready to launch your next app you’ll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200Gbit network, all controlled by a brand new API you’ve got everything you need to scale up. Go to podcastinit.com/linode to get a $20 credit and launch a new server in under a minute. Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email hosts@podcastinit.com) To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media. Join the community in the new Zulip chat workspace at podcastinit.com/chat Your host as usual is Tobias Macey and today I’m interviewing Michael Foord mockingly, about his career in Python Interview Introductions How did you get introduced to Python? One of the main threads in your career appears to be software testing. What aspects of testing do you find so interesting and how did you first get exposed to that aspect of building software? How has the language and ecosystem support for testing evolved over the course of your career? What are some of the areas that you find it to still be lacking? Mock is one of your projects that has been widely adopted and ultimately incorporated into the standard library. What was your reason for starting it in the first place? Mocking can be a controversial topic. What are your current thoughts on how and when to use mocks, stubs, and fixtures? How do you view the state of the art for testing in Python as it compares to other languages that you have worked in? You were fairly early in the move to supporting Python 2 and 3 in a single project with Mock. How has that overall experience changed in the intervening years since Python 2.4 and 3.2? What are some of the notable evolutions in Python and the software industry that you have experienced over your career? You recently transitioned to acting as a software trainer and consultant full time. Where are you focusing your energy currently and what are your grand plans for the future? Keep In Touch Email Website Twitter Picks Tobias -Ology Books Michael Imaginary Authors Falling Into The Sea City On Fire Links IronPython London IronPython in Action Mock UnitTest Play By Email Smalltalk Regular Expression Dijkstra’s Algorithm urllib2 Resolver Systems TDD (Test-Driven Development) PyCon Trent Nelson Fractals Unicode Joel Spolsky (Unicode) OOP (Object-Oriented Programming) End-to-end Testing Unit Testing Canonical Selenium Ansible Ansible Tower AWX (Open Source Tower Codebase) Continuous Integration Continuous Delivery Agile Software Development GitHub GitLab Jenkins Nightwatch.js py.test Martin Fowler Monkey Patching Decorator Context Manager autospec Golang 2to3 Six Instagram Keynote Trans-code Django Girls PyLadies Agile Abstractions David Beazley The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA