This week, it’s my pleasure to interview Brian Okken. Brian is perhaps best known as the author of Python Testing with pytest, as well as being the host of two podcasts. Read on to find out more about the man behind the voice, his new meetup in Portland, and the advice he has for anyone new to testing software.
Ricky: Let’s start with the same questions I ask all my guests. How’d you get into programming? When did you start using Python?
Brian: When I was probably 14 I received a TRS-80 as a gift from my parents. I didn’t really learn to code on that, but I did type in BASIC program listings for small applications and games from the backs of magazines. Then I took a BASIC class in high school, but I didn’t take it much further than that. I didn’t know you could make a career out of it.
I didn’t come back to programming until 2 to 3 years into university when I switched from math and fine arts to CS. I’d used Scheme, Perl, Tcl, C, C++, and ksh by the end of my Bachelor’s and Master’s, both in Computer Science. Then, I joined a test and measurement company building electronic test systems and instruments.
In the early 2000s, a Python-based test framework was introduced to our team. Even though I was developing embedded C++ code, my use of Python to drive the testing of the system has grown and grown over the years. Since I started blogging and podcasting in 2012 and 2015, I’ve expanded my use of Python, both inside projects and on the job, to the point that it’s now where I spend most of my time.
Ricky: What drew you into testing software as a profession? And what do you enjoy most about it?
Brian: I kinda love that question and cringe at the same time. I’ve never been in “software testing” as a profession. But I guess that’s a lot of what I do, anyway.
Successful, effective, efficient software development includes software testing. We rely on solid, dependable, thorough, yet fast test suites to give us the green light for merges during CI/CD pipelines. More and more, we lean on the quality of automated testing to ensure the quality of our software. This enables us to develop faster, ship faster, iterate faster, pivot faster, make mistakes and learn from them faster, and so much more.
And yet, very few developers know how to efficiently and effectively write automated tests that deliver on all of those responsibilities that we put on automated test suites. Many are told (or believe) that they need to write unit tests, without really knowing what that means. Most believe in the test pyramid in theory, but don’t really use it or know what it implies. So, my work has gradually turned to beating the drum and sounding the horn and standing on the podium, singing the praises of automated tests and trying to teach people how to do it.
I like to learn about problems from the first implementation of some code, the first draft. And I really love to write second drafts, third drafts, and so on. I like to tinker with software projects. I like to rip out ugly parts and try to make it readable, or at least less ugly. And in order to do that, I need to rely on tests to tell me if I’ve mucked something up.
That’s the core of it. I want to play with software, so I want to spend as little time as possible writing tests and debugging and triaging issues. That way, I can spend as much time as possible writing new stuff and refactoring old stuff. I want to develop software that I’m proud of. Automated software tests allow that. I don’t know of any other way. That’s what I enjoy the most from testing.
Ricky: For our readers that are new to testing (and perhaps programming in general), what’s the one piece of advice you would give them?
Brian Don’t put off testing till the end. You don’t have to do it first. You don’t have to do Test Driven Development. But also don’t do it last. Build up tests as you build up code, and build up knowledge.
Your automated tests should allow you to develop faster because you aren’t having to go back and manually check all the stuff that used to work. If it feels like adding automated tests is increasing your workload, a few things may be going on. Maybe you’re just new at it, and learning a new skill takes time. You may be writing too many tests. Testing at higher levels, or bigger chunks, or parametrization, or all of the above may make your test writing time more efficient.
Testing isn’t easy. But it’s also not complicated. Allow yourself time to learn. Testing allows you to learn about your software. The learning will help you develop better software. That learning is valuable, so be very careful about being willing to give that learning to someone else. Teams that have engineers develop their own tests will build better engineers than teams that toss the testing to a separate team.
I guess that’s way more than one bit of advice. :)
Ricky: If you could predict the future, what would you predict will be the biggest challenge you see in how we’ll test software in the future?
Brian: Unless something is changing right now, the future will have the same challenges we have now. People that teach programming are not teaching testing hand in hand with development. Compare that with electrical engineering. An EE graduating with a Bachelor’s or Master’s will have spent tons of time with oscilloscopes, logic analyzers, spectrum analyzers, frequency counters, power meters, and other pieces of equipment to validate that their circuits and systems work as expected.
Yet for CS, we don’t spend very much time at all, if any, making sure graduates know how to validate the software they build. And the internet is a mess of conflicting information. It’s really not surprising that testing is so misunderstood. I’m trying to make a dent in it. But really, the biggest challenge is education and countering old assumptions.
Ricky: I would be remiss if I didn’t mention the podcasts you host (Test and Code) and co-host (Python Bytes). Have there been any lessons or learning experiences from podcasting that have transferred over to your code? And has it helped you level up your programming in any way?
Brian: There are so many lessons! But I think the most important thing I’ve learned is the importance of developing the skill of listening and practicing it often. Asking questions is a great way to learn things, but it only works if you let yourself listen and hear the answer. I’ve had to edit out follow-up questions from episodes when, during editing, it was obvious that I hadn’t really listened to what the interviewee had already told me.
Careful listening is harder than we give it credit for, and so freaking powerful. Being a better listener definitely carries over into all other parts of my life, including management, programming, testing, and even family.
Ricky: Last but not least, when you’re not writing code, what else do you get up to in your spare time? What other hobbies and interests do you have? Anything you’d like to plug?
Brian: I most like spending time with my wife and kids. My wife and I have always been collectors of beautiful antique and vintage items, and we’ve tried to build a home full of eclectic, theatrical elements. We treat our living space as a giant shadow box art installation. More recently, that interest has moved into retail and we sell through a local antique mall. Feel free to see pics on Instagram, where we are FrivolityPDX.
I just started up the Python PDX West Meetup for West Portland with my Python Bytes co-host Michael Kennedy. I also wrote a book. Not only will you learn to use pytest very well, but you’ll also get lots of testing strategy advice in a book short enough to read in a weekend. Python Testing with pytest can be found at Pragmatic or on Amazon. And please, listen to Test & Code. Testing is not just about testing, it’s about development. Same goes for the podcast. That’s why there’s an “& Code” part in the name. :)
Thank you, Brian, for joining me for this interview! It’s been great having you on the other side of the interview mic (so to speak).
As always, if there’s someone you’d like me to interview in the future, then reach out to me in the comments below or send me a message on Twitter.
