Test Classes: No OO experience required

Transcript for episode 5 of the Test & Code Podcast

This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.

In this episode, test classes, no object oriented experience required. You do not need to understand object oriented programming to make use of test classes. They are a way of organising code, and they allow a granularity between module and function. This episode covers some of the confusion around using test classes, and a few benefits of them.

[music] Hello everyone, my name is Brian Okken and welcome to the Python Test Podcast. Last week I started a contest. This week, I’m going to expand the rules, announce a couple of winners, and announce a super duper bonus prize, so stick around to the end and find out more details. [music]

[0:51] With Unittest, you have to use classes, you have to derive from TestCase. With Pytest and Nose, you don’t have to use classes. That is one of the appealing things about Pytest and Nose. The test functions can just be functions, they don’t have to be in a class. But they can be. I almost always start writing out test code with code outside of classes, just functions. Just some test functions in a module with other test functions that are testing the same functionality, or something closely related. But there often comes a point where it makes sense to pull some of the functions into a class.

Before I get into that, I need to address the object oriented thing. There are people who are uncomfortable with object oriented programming. One of the reasons to not want to use test classes is because of this uneasiness with object oriented stuff. I have no problems with object oriented design and object oriented programming, but I totally get that uneasiness. That’s why I want to say that test classes have very little to do with object oriented programming. Of course you can go crazy with inheritance of test classes and do some pretty cool things. Contract tests are one example. But you don’t have to. You can, and often should think of test classes as mere containers to put some of your tests in, when you want to group them in some granularity smaller than a module.

[2:18] Let’s go through some of the reasons to group some tests into a class. The first is this test run granularity. You can run all of your tests, or just those in one directory, or those in a file, or a module. If you have a group of related tests in a module that you want to run together, then the easy way to do this is to group them into classes. I’ve got a post describing how to run a single test class, I’ll link to that in the show notes. The second reason is test functions in a class can share fixtures. For instance, let’s say I’ve written a bunch of tests and I realise that many of them require the same preconditions. If the preconditions need to be set up before every test, they can be defined as method scope fixtures in Pytest, as setup method functions in really everything, and all the tests in a class can use them. If the preconditions can be set up once before all the tests, then the setup can be done at the class scope, or setup class functions. Then the setup code will run once and then all the tests in the class will be able to run, and then the teardown code saves some time. Either way, it keeps the shared fixtures close to or within the class that uses the fixtures. Third reason that I often use classes is to allow one more level of fixtures for reducing setup time. Just makes things easier sometimes. Here’s an example. I’ve got some tests that check a measurement on an instrument using an arbitrary waveform generator. It makes sense to put in module scope fixture the connection to the arb, resetting it and setting and settings that are shared by all the tests. You then group all of the tests that use the same waveform into classes based on what waveform they need, and then I write a class scope fixture to set up the waveform, or set the waveform file or whatever. Then the tests can just run, with no method scope fixtures, or maybe I’ve got a couple of extra settings in the method scopes.

[4:28] There are other great uses for test classes, but that’s really what I wanted to cover today. You can use them for a granularity of test runs, somewhere between module and function. The test functions in a test class can share fixtures, and the extra level of fixtures can save setup time, makes sense sometimes. That’s really what I wanted to cover today. [music]

This show is brought to you today by the Patreon supporters. Sign up at patreon.com/okken. Also by all of the supporters of the show that have supported by purchasing Python Testing with Unittest, Nose and Pytest. [music]

[5:17] One of the challenging things I’ve done in my career is transitioning from engineering to leadership. I’ve been a team lead for a couple of years now. It’s like being a manager and an engineer at the same time. One of the best books that have helped me through this transition is “Leading Snowflakes” by Oren Ellenbogen. It’s kind of a cool name, do you get it? Software developers are all different like snowflakes, anyway. It’s a great book and I recommend it, even for non-managers. I contacted Oren about including the book in this contest, and he agreed to it, which is cool. So, in early November, I’m going to pick one person from all the entries. This will be a random selection, and they will receive my book, if they don’t already have it, Oren’s Leading Snowflakes, in pdf, mobi and epub, and he’s also including the ten interviews that he’s done with managers from Yammer, Twitter, Hubspot, Khan Academy, Soundcloud, New Relic, Netflix, Etsy, Quora and Palantir, probably got that one wrong. But that last one, that’s Michael Lopp, Rands himself. Thanks a bunch to Oren for donating this. I’ll announce the winner of this prize early in November. Entries through the thirty-first of October. I am expanding the rules. I’ve realised that having a contest based on iTunes reviews is kind of lame, because a lot of people don’t use iTunes, so expanding the contest. Everyone who buys my book right now will be entered into the bonus prize. And also anybody that signs up on Patreon will be entered. So, there’s more though. If you spread the word about this show, any way possible, I’ll enter you. Tweet about it, and include @testpodcast, I see those. Of course, still rate it on something. Rate it on iTunes, Stitcher, Soundcloud, whatever you can rate it on, rate it on that and email me to let me know. Email some friends of the show, anything else you can think of, any way to expand the reach of the show, and just let me know what you did, and that will enter you. That’s pretty easy. Thanks a lot! [music]