Parametrizing Fixtures

In ​Parametrized Testing​, we parametrized tests. We can also parametrize fixtures. We still use our list of tasks, list of task identifiers, and an equivalence function, just as before:

But now, instead of parametrizing the test, we will parametrize a fixture called a_task:

The request listed in the fixture parameter is another builtin fixture that represents the calling state of the fixture. You’ll explore it more in the next chapter. It has a field param that is filled in with one element from the list assigned to params in @pytest.fixture(params=tasks_to_try).

The a_task fixture is pretty simple—it just returns the request.param as its value to the test using it. Since our task list has four tasks, the fixture will be called four times, and then the test will get called four times:

We didn’t provide ids, so pytest just made up some names by appending a number to the name of the fixture. However, we can use the same string list we used when we parametrized our tests:

This gives us better identifiers:

We can also set the ids parameter to a function we write that provides the identifiers. Here’s what it looks like when we use a function to generate the identifiers:

The function will be called from the value of each item from the parametrization. Since the parametrization is a list of Task objects, id_func() will be called with a Task object, which allows us to use the namedtuple accessor methods to access a single Task object to generate the identifier for one Task object at a time. It’s a bit cleaner than generating a full list ahead of time, and looks the same:

With parametrized functions, you get to run that function multiple times. But with parametrized fixtures, every test function that uses that fixture will be called multiple times. Very powerful.

Parametrizing Fixtures in the Tasks Project

Now, let’s see how we can use parametrized fixtures in the Tasks project. So far, we used TinyDB for all of the testing. But we want to keep our options open until later in the project. Therefore, any code we write, and any tests we write, should work with both TinyDB and with MongoDB.

The decision (in the code) of which database to use is isolated to the start_tasks_db() call in the tasks_db_session fixture:

The db_type parameter in the call to start_tasks_db() isn’t magic. It just ends up switching which subsystem gets to be responsible for the rest of the database interactions:

To test MongoDB, we need to run all the tests with db_type set to mongo. A small change does the trick:

Here I added params=[’tiny’,’mongo’] to the fixture decorator. I added request to the parameter list of temp_db, and I set db_type to request.param instead of just picking ’tiny’ or ’mongo’.

When you set the --verbose or -v flag with pytest running parametrized tests or parametrized fixtures, pytest labels the different runs based on the value of the parametrization. And because the values are already strings, that works great.

Installing MongoDB
	To follow along with MongoDB testing, make sure MongoDB and pymongo are installed. I’ve been testing with the community edition of MongoDB, found at https://www.mongodb.com/download-center. pymongo is installed with pip—pip install pymongo. However, using MongoDB is not necessary to follow along with the rest of the book; it’s used in this example and in a debugger example in Chapter 7.

Here’s what we have so far:

Hmm. Bummer. Looks like we’ll need to do some debugging before we let anyone use the Mongo version. You’ll take a look at how to debug this in ​pdb: Debugging Test Failures​. Until then, we’ll use the TinyDB version.