Today I’m joined by Bruno Oliveira, who is perhaps most well known for being a pytest core developer. In this interview, we cover migrating a large codebase from C++ to Python, how to get started with pytest, and his love of Dark Souls.
Ricky: Welcome to Real Python, Bruno. I’m glad you could join us. Let’s start in the same manner we do with all our guests: How’d you get into programming, and when did you start using Python?
Bruno: Hi, Ricky. Thanks for having me.
I started programming twenty-three years ago or so. I was just getting into computers when a friend of mine showed me this book about Visual Basic, and I was absolutely amazed that you could write your own calculator.
Sometime later, my dad bought me the Delphi 3 Bible. I devoured that, and after a while I started to program in DirectX and make very simple games.
After that, I went into college, and in the second semester I managed to get an internship to work on a Delphi application for image processing. After the internship, I joined ESSS, which is the company I work at to this day.
My role at ESSS as a technical leader is to manage the technical aspects of the projects I work on, including design and day-to-day code reviews. I’m involved in four projects currently.
Along with the other technical leaders, I also develop and oversee our high-level efforts, such as migrating all the code from one Python version to the next, solving problems in our CI, implementing development workflows, and many others.
At ESSS, we develop engineering applications specifically for the oil and gas industry. When I joined, everything was coded in C++, and the team developed everything themselves, including a multiplatform GUI library. A year or so after I was hired, we started looking into Python (version 2.4 at the time) and how we could use it together with PyQt for quickly developing our applications.
Today, we have the vast majority of our codebase in Python, with some C++ thrown in for simulations and numeric computation. In January 2019, we completed the move of all projects from Python 2 to Python 3 (version 3.5 at the time), which was an effort involving the entire team working whenever we could for over four years.
Ricky: You’ve been a core developer of pytest for quite some time now. How did you discover pytest, and why did you take the leap to become one of its contributors?
Bruno: Ever since we started using Python, we immediately saw the value of automated testing, and not just because Python is dynamic. When all our code was plain C++, the applications would crash all the time, even with the relative safety of having a compiler.
We evolved our testing code base organically, adding support for Qt, parallelism, rich test collection, and so on. Around 2013, I discovered pytest and was amazed by the library. It contained everything we had implemented in-house plus a bunch of things we wanted, and it also featured a very expressive plugin system that could then be extended to the features that were not yet available.
I’ve always loved automated testing, so around that time I created the pytest-qt plugin, and pytest-mock was created right after that. I then started to get involved in the mailing list and contributing bug fixes and new features. Eventually the creator of pytest, Holger Krekel, turned me into a core developer.
A few years later, we managed to replace all of our custom testing code base with pytest and plugins.
Ricky: At the time of this interview, pytest 6.0 is currently in the release candidate stage. What are you most excited about with the new release? Are there any new features that might change the way people are testing their code?
Bruno: I think the most exciting feature for many is that pytest is now fully type annotated, allowing users to use mypy for type checking their testing code. This took many months of effort and was spearheaded by one of our newest core contributors, Ran Benita.
Another long-awaited feature is the ability to use pyproject.toml files for configuration.
Ricky: You’ve also authored a book with Packt Publishing called pytest Quick Start Guide: Write better Python code with simple and maintainable tests. How did you find the experience of writing a book, and how has the process helped you with your own Python testing?
Bruno: While it’s fun trying to come up with code examples that are different from what we usually see in programming books and articles, like Dark Souls and TV references, the overall experience was a bit exhausting, to be honest.
This has nothing to do with the publisher and editors, who were really helpful. It’s just that I don’t think I have a passion for it, so everything was hard work compared to programming, which is something I love and that gives me pleasure.
But the overall experience was positive. Having to write down a bunch of patterns, such as how to port large test suites from unittest to pytest, in an easy-to-understand manner helped me to solidify them in my mind.
Ricky: For any beginners reading this, why is it important to test your code, and how might one get started with pytest?
Bruno: Writing automated tests is not much different from what most people already do when they write new code. Often they will open up the REPL to quickly try something out, like this:
>>> from mymodule import mysum
>>> mysum(4, 5)
9
>>> mysum(1, -1)
0
>>> # Woot! it works
People might also write some quick code under if __name__ == __main__: in the module, like this:
if __name__ == "__main__":
print(mysum(4, 5))
print(mysum(1, -1))
# See that it prints '9' and '0' and woot! it works
While this is suitable to see if things are working, making the leap to write an automated test is very simple. All one needs to do is create a test_mymodule.py file and write the following:
def test_mysum():
assert mysum(4, 5) == 9
assert mysum(1, -1) == 0
That’s it. Now you can execute pytest, and it will check that mysum() still works. While it might seem silly at first to test something when you already know it works, the important thing to realize is that this automated test ensures that the function will keep working in the future. The more tests you add, the more of your entire system is being validated all the time.
This is the brilliant part of automated testing for me. It ensures not only that your system works, but also that it will continue to work in the future, even if you decide to refactor everything. At the very least, it will point out any mistakes you may make. Manual testing just doesn’t scale.
Ricky: Now for my last few questions. What else do you get up to in your spare time? What other hobbies and interests do you have aside from Python and programming?
Bruno: I really enjoy watching TV series (who doesn’t?) and gaming on my PC. I’m a huge Dark Souls fan, and I really enjoy playing rich RPGs like The Witcher 3 and cooperative multiplayer games with my friends.
Ricky: Thank you for joining me, Bruno. It was a pleasure.
If you’d like to get in touch with Bruno, you can find him on Twitter. You can also grab a copy of his book.
If there is someone in the Python community that you’d like me to interview, then leave a comment below or reach out to me on Twitter.
Happy coding!
