pytest book 2nd edition
  • 2nd edition is now in print and shipping from various booksellers.
  • eBook
    • is available through Pragmatic
    • includes pdf, epub, and mobi (for Kindle)
  • paper editions

Why a Second Edition?

This section is an excerpt from the Preface, which is available to read as a larger excerpt on the books Pragmatic page.

Both Python and pytest have changed since the first edition of this book was published in 2017. There have been updates to pytest that are now reflected in the book, such as:

  • New builtin fixtures
  • New flags
  • The addition of package scope fixtures

There have also been updates to Python that are reflected in the book:

  • The adoption of f-strings and pathlib
  • The addition of dataclasses

Also, since publication of the first edition, I have taught many, many people about pytest, and I think I’ve learned how to be a better teacher. The second edition not only expands on what is covered in the first edition—it grew from 7 to 17 chapters!—but also it presents the material in what I think is a more gradual, digestible manner.

So what’s in all of these new chapters?

  • More on parametrization, markers, coverage, mocking, tox and continuous integration, and third-party plugins. All of these topics were covered in the first edition, but in this edition I expand that coverage. I pulled the discussion of parametrization into its own chapter and added a discussion of advanced parametrization techniques. I delve more deeply into markers and include an example of how to pass data from markers to fixtures (which is super cool). I also take you on a deeper dive into test coverage, mocking, and CI, and using and building your own plugins to extend pytest’s capabilities.

  • A discussion of test strategy. Feedback from the first edition was that the book was great for the mechanics of how to use pytest, but the “What test do I write?” information was a bit lacking. The new Chapter 7: Strategy is push in the right direction of what tests to write. A complete treatment of test strategy would be a book in itself; however, this chapter will get you started.

  • Information about the Python search path. A lot of readers reached out to me asking about how to get their tests to see their test code, and the first edition didn’t cover it. The project in this book, Cards, doesn’t have that problem because it’s an installed Python package. However, lots of user projects are applications or scripts or lots of other things that are not installed packages. This chapter offers a focused look at the problem and provides some solutions.

I moved coverage of command-line flags and configuration settings in general to their own chapter at the end of the book where, after you’ve learned the basics of pytest, you can check out the ton of cool options that can help you run your tests more efficiently and effectively.

Also, I consolidated the information about debugging test failures into a chapter of its own. In the last edition, this information was spread all throughout the book. It is my hope that when you are faced with a deadline and a failing test suite, bringing this information together into one chapter will help you figure an answer out quickly and ease some stress.

Finally, the example project changed. The first edition used a project called Tasks to illustrate how to use pytest. Now it’s called Cards. Here’s why:

  • It’s easier to say out loud. (Try it. Say “tasks” three times, then “cards” three times. Right?)
  • The new project itself is different because it uses Typer instead of Click for command-line functionality. Typer code is easier to read.
  • The project also uses Rich for formatting the output. Rich didn’t exist (neither did Typer) when the first edition was written.

The code examples have also been simplified. The directory structure of the first edition code examples followed a progression of a possible test directory within a project, with most of the project removed. Seriously, I think it made sense to me at the time. In this edition, there is a project in its own directory, cards_proj, with no tests. Then each of the chapters have test code (if appropriate) that either work on the one project, or on some local code. Trust me, I think you’ll agree that it’s way easier to follow along now.