Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson

Already subscribed? Sign In


    Write Your First Python Unit Test with pytest

    Will ButtonWill Button

    In this lesson you will create a new project with a virtual environment and write your first unit test with pytest. In doing so, you will learn:

    • install pytest
    • organize your project to support automated test discovery
    • setup Visual Code to use pytest as your test engine
    • best practice naming conventions for tests in Python


    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson


    Instructor: 00:01 We'll start by creating a new project. We'll create a virtual environment inside of that folder. Virtual environments work well for me, because at any time, I can have quite a few different Python projects open with different dependencies.

    00:15 Using virtual environments ensures that I don't have any dependencies clobbering one another. Whenever I package this up, I'll only package in the dependencies that this application needs, not all the dependencies for all the Python projects I have open. Then, I'll install Pytest and Pylint.

    00:37 Now, I can open up Visual Code as my editor, and we'll start building on our project. We're going to do a little function here that does some basic math, so I'm going to create a Python file called CommonMath. Inside of that, we'll have a function called Add, that receives two parameters, number one and number two. For right now, we'll say it returns foo. Then, I'm going to create my test folder structure.

    01:03 The way Pytest works is it looks for a sub-directory called, "Test." It'll search for files that begin with the name Test_, inside of that folder. Then, the naming convention is that the name of the file follows the name of the file that it's testing. Our test file for CommonMath will be,

    01:27 Now, when I wrote CommonPath, so let's fix that. Inside of my test file, I'm going to import Pytest. I'm going to import the file that we're going to be testing, which is CommonMath. I'm going to create a class that will contain all of our tests. Inside of there, we'll have our functions that test each individual function in the file.

    01:50 We're going to test this function called Add. Our first function will be called Test_Add. It receives itself as a parameter. For right now, we'll pass that test. Now, since I'm using Visual Code, I need to do a little bit of set-up within Visual Code so that it knows how to use Pytest. First thing I'm going to do is enable Pytest, Python.unittest.pytestenabled will be set to true.

    02:19 I need to set my arguments for it. I'm going to set ignore equal to .env, so that it doesn't try to test my virtual environment, and then, -s so that crawls subdirectories. Then, there's one other thing you have to do here that is specific to using Visual Code. If you're not using Visual Code, you can ignore this part, but we need to set the environment file.

    02:41 We're going to set that to a file called .envfile. Then, over here we'll need to create that file. Then, we do that because there's a current bug in Visual Code that's going to prevent it from finding our test or finding the test directory without that file. With all that set up, you can see now that I've got little hover menu options here to run the test.

    03:04 We can click Run Test. If we want to show the output, one test passed. The test passed because it didn't actually do anything. We just set it to pass. We can instead say Result is equal to CommonMath.add and provide our two numbers. Then, we'll say Assert Result is equal to three.

    03:29 I'll save that. If I click Run, that test is going to run. The test is going to fail. It fails because foo is not equal to three, and that's a common tenet of using test-driven development. You write a failing test first, and then, you write the code to make that test pass. Now, I can actually say num1 will return num1 + num2.

    03:55 Save that, and we can run our test again. That test passed.