Django Testing Tutorial with Pytest #3 - Coverage (2018)

Summary

This video tutorial teaches viewers how to refactor common setup code into functions and measure test coverage in Django. It demonstrates using the 'setUpClass' method to streamline test setup, reducing redundancy and improving performance. The video also guides on setting up a test coverage report with 'coverage', customizing it to exclude unnecessary files, and viewing results in an HTML format for a clear understanding of code execution coverage.

Takeaways

• 🔧 Extract common setup code into its own function to improve code organization and performance.
• 📈 Use Django's TestCase for unit testing to gain access to the 'setUpClass' method for shared setup tasks.
• 📝 Call the 'super().setUpClass()' to ensure the base class's setup is executed before custom setup code.
• 🔄 Instantiate shared objects like 'requestfactory' once in 'setUpClass' to avoid redundancy and improve efficiency.
• 📑 Utilize 'setUpClass' as a decorator to ensure the method is run once for the class, not every time a test is executed.
• 📊 Set up test coverage reports to measure the effectiveness of your tests and identify untested code.
• 🛠️ Install necessary packages to enable test coverage reporting if not already present in your environment.
• 📋 Use the 'coverage' flag with 'pytest' to generate a coverage report, indicating the percentage of code executed during tests.
• 📁 Exclude irrelevant files such as test files, migrations, and certain configuration files from the coverage report for accuracy.
• 📝 Create a '.coveragerc' file to specify directories and files to omit from the coverage report for cleaner results.
• 🌐 Use 'pytest' options like '--cov-report=html' to export the coverage report in an HTML format for easy visualization.
• 🔄 Regularly review and adjust test coverage to ensure all critical parts of the application are adequately tested.

Q & A

What is the main purpose of the video?

The video teaches viewers how to refactor common setup code into a separate function and how to measure test coverage in a Django project.

Why is it necessary to extract the mixer of blend line code into a separate function?

Extracting the mixer of blend line code into a separate function is necessary because it's not part of the main function's behavior but is required for the code to run successfully, avoiding failures due to missing objects with a private key of one.

What is the benefit of instantiating the requestfactory object only once?

Instantiating the requestfactory object only once improves performance, especially when there are many test functions, as it reduces the overhead of creating the object multiple times.

How does the 'setup_class' method in Django's TestCase work?

The 'setup_class' method in Django's TestCase is a class method that runs before all other test methods in the class. It is used for setting up code that needs to be executed once for the entire test class.

What is the purpose of the 'super' function in the 'setup_class' method?

The 'super' function is used to call the 'setup_class' method of the parent class (TestCase) to ensure that any setup actions defined in the parent class are also executed.

Why is it important to measure test coverage in a project?

Measuring test coverage is important to ensure that the codebase is adequately tested. It helps identify untested parts of the code which could lead to potential bugs or issues in production.

What does the '--coverage' flag do when running tests with 'manage.py test'?

The '--coverage' flag generates a test coverage report, showing which parts of the code are covered by tests and which are not.

How can you specify which files to exclude from the test coverage report?

You can specify files to exclude from the test coverage report by setting the 'omit' option in the '.coveragerc' file to the paths of the directories or files you want to omit.

What is the benefit of exporting the test coverage report to an HTML format?

Exporting the test coverage report to an HTML format makes it easier to navigate and visually inspect which parts of the code are covered by tests. It also provides a more user-friendly way to review the report.

How can you open and view the HTML coverage report in an editor like Atom?

You can open and view the HTML coverage report in Atom by installing the 'atom-html-preview' package, then opening the 'index.html' file and using the shortcut 'Ctrl + Shift + H' to preview it.

What should you consider when deciding which files to include or exclude from test coverage measurement?

You should consider excluding files that do not require testing, such as test files themselves, migration files, and certain configuration files like 'wsgi.py'. These files are typically not the focus of test coverage as they are either tested by definition or do not contain executable business logic.

Outlines

00:00

🔧 Refactoring and Test Coverage in Django

This paragraph discusses the process of refactoring common setup code into a separate function to improve performance and maintainability in Django. It explains how to use the `setUpClass` method from Django's TestCase to instantiate objects like the RequestFactory only once for all test methods within a class. The speaker also demonstrates how to use the `@classmethod` decorator to pass class parameters effectively. The focus then shifts to measuring test coverage using the `coverage` flag with `pytest`, showing how to generate a comprehensive report and how to adjust settings to exclude unnecessary files from the coverage analysis.

05:02

📊 Enhancing Test Coverage Reporting

The second paragraph delves into enhancing the test coverage report by using an Atom plugin for HTML preview, which allows for a more user-friendly way to view the coverage report. It describes how to install the Atom HTML preview plugin and use it to open the index.html file generated by the test coverage tool. The paragraph further explains how to exclude test files from the coverage report by creating a `.codecovrc` file with the `omit` key set to specific directories. The speaker illustrates the impact of including or excluding these files on the coverage percentage and emphasizes the importance of maintaining a clean and accurate test coverage report for better code quality assurance.

Keywords

💡Function

In the context of the video, a 'function' refers to a block of organized, reusable code that is used to perform a single, related action. The script discusses extracting common setup code into its own function to improve code organization and performance. For example, the script mentions creating a function to instantiate the 'requestfactory' object, which is used in multiple places, to avoid redundancy and enhance efficiency.

💡Test Coverage

Test coverage is a measure used in software testing to describe the degree to which the source code of a program is tested by a particular set of test cases. The script explains how to measure test coverage using the 'coverage' flag with the 'pytest' command, which helps identify untested parts of the code. The video demonstrates achieving 100% test coverage, indicating that every part of the code has been executed by the test suite.

💡Mixer

In the script, 'mixer' refers to a specific line of code that is used to create an object with a private key of one. It is mentioned as a part of the setup code that is not directly related to the main function's behavior but is necessary for the tests to run successfully. The script suggests that this line should be moved to a setup function to avoid repetition.

💡RequestFactory

The 'RequestFactory' is a class in Django's testing framework that allows for the creation of request objects in tests. The script discusses the instantiation of this object multiple times and suggests extracting its creation into a setup function to improve performance and reduce redundancy. This is demonstrated by assigning 'RequestFactory' to a variable 'factory' and using it in test functions.

💡Setup Class

The 'setup class' method in the script refers to a special method in Django's testing framework that is run before any tests in a test class are executed. It is used to set up any necessary preconditions for the tests. The script explains how to use the 'setup class' method to instantiate objects that are used across multiple test functions, thus ensuring they are only created once.

💡Subclass

In object-oriented programming, a 'subclass' is a class that is derived from another class, known as the superclass. The script mentions subclassing from 'TestCase' to gain access to the 'setup class' method. This is a way to extend the functionality of the existing 'TestCase' class with custom setup logic for the tests.

💡Django

Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. The script refers to Django's default unit test module, which is used for writing and running tests in a Django project. The video demonstrates how to integrate Django's testing framework with pytest for improved testing capabilities.

💡Performance

In the context of the video, 'performance' refers to the efficiency and speed of executing code, particularly in the context of running tests. The script suggests improvements to enhance performance, such as reducing the instantiation of objects like 'RequestFactory' to once per test class, rather than multiple times per test function.

💡HTML Coverage Report

An 'HTML coverage report' is a detailed report generated by the coverage tool, which is presented in HTML format for easy visualization of test coverage. The script explains how to generate this report using the '--coverage-report=HTML' option with the 'pytest' command, allowing developers to view which parts of the code have been tested and which have not.

💡Atom Plugin

In the script, an 'Atom plugin' refers to an extension for the Atom text editor that adds functionality or enhances the user experience. The video mentions the 'atom-html-preview' plugin, which allows for the convenient viewing of HTML files, such as the coverage report, directly within the Atom editor.

💡.coveragerc

The '.coveragerc' file is a configuration file used by the coverage tool to specify settings for generating coverage reports. The script explains how to create and use this file to omit certain directories, like 'tests' and 'migrations', from the coverage report, focusing only on the parts of the codebase that are relevant for testing.

Highlights

Learning to extract common setup code into its own function for efficiency.

Understanding the importance of creating an object with a private key of one for successful test execution.

Instantiating the requestfactory object in multiple places for performance improvement.

Using Django's standard unit test module with pytest for better test management.

Subclassing from TestCase to access the setUpClass method for setup code execution.

Calling the actual setUpClass of the TestCase to ensure proper setup sequence.

Instantiating the requestfactory object once to avoid redundancy and enhance performance.

Utilizing the setUpClass decorator to automate class parameter passing.

Running tests with the --coverage flag to measure test coverage.

Achieving 100% test coverage as indicated by the coverage report.

Excluding unnecessary files like manage.py and wsgi.py from test coverage calculation.

Configuring pytest to add options for consistent test coverage reporting.

Exporting coverage reports into HTML format for easier visualization.

Using an Atom plugin for HTML preview to conveniently view coverage reports.

Creating a .coveragerc file to specify directories to omit from coverage reports.

Ensuring test files and migrations are excluded from the coverage report for accuracy.

Demonstrating the impact of not having test coverage with a drop to 95% coverage.

Highlighting the necessity of test coverage for identifying untested code segments.

Encouraging viewers to stay tuned for the next part covering fixtures in testing.

Transcripts

here you all I hope your day's going

great in this video you will learn how

to extract common set up code into their

own function and how to measure test

coverage as you can see we are using

this mixer of blend line twice right

here and right here as well and really

it's not part of the main function

behavior it's just some code that we

need in order to run this line because

as you can see we are relying on having

an object with the private key of one

and if we didn't run this line to create

one with the private key of one then

there wouldn't be would be none so of

course it will fail and also we are

instantiating the requestfactory object

in on in two different places and you

know there's some room for improvement

as well in regards to performance so PI

test works quite well with the standard

unit test module which django uses by

default and we can go to the top and

import test case so that's inside of

Jenga your test you can just import test

case and then from our class you can

subclass from test case and by doing so

we are granted access to a method which

is called setup class and everything

that we put inside of that function will

be running every you know before running

all of these other functions inside of

this class so def setup class and this

one takes in the extra class instance

and first of all we need to call the

actual setup class of this test case and

to get access to that we need to call

super test views and passing the class

don't set up class and this really just

calls set up class of this test case and

then we can override everything that we

want to do after that and the first

thing is this line because that you know

we only need to instantiate it once

really because we are using the same

object here and here both should have

deprived give one get rid of that one

and then also this requestfactory we can

extract that and now we want to set plus

though I'm just going to call this

factory equal to request factory and

then inside of our single functions we

can call self the factory and in here

also self or factory and that should

work and now what we need to do is if

this set up plus the decorative class

method and this is because we want to

get the class you know parameter passed

and the class method will take care of

that for us

and now we can just enter the terminal

again and run high test and as you can

see it still runs the same way it did

before only that we are instantiating

the requestfactory object once and also

this mix it up plan once and if we have

like one or two hundred separate test

functions it should run faster this way

because we are only doing once as I said

so next up we want to setup the test

coverage report and for this one we

already install the package in the first

part so just simply go into your time

terminal and now you can type in high

test and at the - - coverage flag and as

you can see we get a total coverage

report and the courage is at 100% and

all of the files which are being tested

are displayed for him and there's one

more option we can set which is pi test

test coverage and then we can set it

equal to a path which we want specified

and if we set it to dot it will get all

of the files but as you can see there

are three files which have a zero

percent test coverage which are managed

of Pi and F so pi and also this WSGI

dope fire and these three files really

we don't want tested so that will you

know Titus is smart enough to figure

that out that we shouldn't test these

and it doesn't by default so that will

be fine and so we don't need to specify

the - - coverage option every time we

can go into the PI test or any file

and use the add options adopts fork

short and set it equal to - - coverage

and then we can specify another argument

called - - coverage report equal to HTML

and this will basically just take care

of exporting our entire coverage report

into HTML format and then it will give

us a file or a directory as you're going

to see in a minute so now back in the

terminal we only need to run my test and

as you can see we get this HTML coverage

folder and inside of that is an indexed

or HTML file and I found that the most

convenient way of opening this is to use

an atom plug-in if you haven't insulted

already you can just go to file then to

settings and to install and then you

just simply search for atom HTML preview

and then hit install on this one and if

that's is done you can open the

index.html file and to simply hit ctrl

shift + H and if you did that correctly

you should see this when they're popping

up and we get our entire coverage report

and just can browse all of the files and

see which ones are being executed but of

course we don't want to test the

coverage of our test files because that

wouldn't really make any sense because

that should always be one percent

basically because those are the files

that are always being executed by us

running the tests so just go back and

I'm just going to close this file and

the PATA so any file and then we can go

into the main directory and create

another file called dot coverage RC and

this one also uses to draw any syntax

and any syntax works by first of all

specifying a section and this one is

called run and then we have normal key

value pairs and the key in this case is

going to be the omit and we can set it

equal to all of the directories we want

to omit from a coverage report and those

are first of all star slash tests and

everything that is inside of the tests

factories in general should be avoided

and then we also have the migrations

which we don't really need to include in

our test coverage report and that should

basically be it because of course the

WSGI to pi EPSA player manager pi should

be excluded by default and just open it

up again

and run PI test then we can go back into

the HTML coverage folder and just open

up in next door HTML again by pressing

ctrl shift

H and you will see that we successfully

in got rid of T test files in our test

coverage report and you know that's

about it for this part we set up test

coverage so you can measure all of the

tests and I'm just going to show you

real quickly how that would look if we

didn't have one upset test coverage so

just get rid of these two functions and

run then run pi test any see it dropping

down to 95% and this user profile only

as 67% can open that one and you can see

these two lines mark red because these

ones weren't executed of course because

we don't have tests for them but if we

insert them back again and rerun pi test

we get 100% as we want it so make sure

to stick around for the next part where

we are probably going to be covering

fixtures and until then make sure to

leave a like if you enjoyed and Cheers