78 captures
25 Jun 2018 - 09 Oct 2025
Oct NOV Dec
25
2019 2020 2021
success
fail

About this capture

COLLECTED BY

Collection: Common Crawl

Web crawl data from Common Crawl.
TIMESTAMPS

The Wayback Machine - http://web.archive.org/web/20201125075901/https://devguide.python.org/runtests/
 

Navigation



index

next |

previous |


Python »
  Python Developer's Guide »  
|  







4. Running & Writing Tests



Note

This document assumes you are working from an in-development checkout of Python. If you are not then some things presented here may not work as they may depend on new features not available in earlier versions of Python.


4.1. Running


The shortest, simplest way of running the test suite is the following command from the root directory of your checkout (after you have built Python):

./python -m test



You may need to change this command as follows throughout this section. On most Mac OS X systems, replace ./python with ./python.exe. On Windows, use python.bat. If using Python 2.7, replace test with test.regrtest.

If you dont have easy access to a command line, you can run the test suite from a Python or IDLE shell:

>>> from test import autotest



This will run the majority of tests, but exclude a small portion of them; these excluded tests use special kinds of resources: for example, accessing the Internet, or trying to play a sound or to display a graphical interface on your desktop. They are disabled by default so that running the test suite is not too intrusive. To enable some of these additional tests (and for other flags which can help debug various issues such as reference leaks), read the help text:

./python -m test -h



If you want to run a single test file, simply specify the test file name (without the extension) as an argument. You also probably want to enable verbose mode (using -v), so that individual failures are detailed:

./python -m test -v test_abc



To run a single test case, use the unittest module, providing the import path to the test case:

./python -m unittest -v test.test_abc.TestABC



If you have a multi-core or multi-CPU machine, you can enable parallel testing using several Python processes so as to speed up things:

./python -m test -j0



If you are running a version of Python prior to 3.3 you must specify the number of processes to run simultaneously (e.g. -j2).

Finally, if you want to run tests under a more strenuous set of settings, you can run test as:

./python -bb -E -Wd -m test -r -w -uall



The various extra flags passed to Python cause it to be much stricter about various things (the -Wd flag should be -W error at some point, but the test suite has not reached a point where all warnings have been dealt with and so we cannot guarantee that a bug-free Python will properly complete a test run with -W error). The -r flag to the test runner causes it to run tests in a more random order which helps to check that the various tests do not interfere with each other. The -w flag causes failing tests to be run again to see if the failures are transient or consistent. The -uall flag allows the use of all available resources so as to not skip tests requiring, e.g., Internet access.

To check for reference leaks (only needed if you modified C code), use the -R flag. For example, -R 3:2 will first run the test 3 times to settle down the reference count, and then run it 2 more times to verify if there are any leaks.

You can also execute the Tools/scripts/run_tests.py script as found in a CPython checkout. The script tries to balance speed with thoroughness. But if you want the most thorough tests you should use the strenuous approach shown above.

4.1.1. Unexpected Skips


Sometimes when running the test suite, you will see unexpected skips reported. These represent cases where an entire test module has been skipped, but the test suite normally expects the tests in that module to be executed on that platform.

Often, the cause is that an optional module hasnt been built due to missing build dependencies. In these cases, the missing module reported when the test is skipped should match one of the modules reported as failing to build when Compile and build.

In other cases, the skip message should provide enough detail to help figure out and resolve the cause of the problem (for example, the default security settings on some platforms will disallow some tests)



4.2. Writing


Writing tests for Python is much like writing tests for your own code. Tests need to be thorough, fast, isolated, consistently repeatable, and as simple as possible. We try to have tests both for normal behaviour and for error conditions. Tests live in the Lib/test directory, where every file that includes tests has a test_ prefix.

One difference with ordinary testing is that you are encouraged to rely on the test.support module. It contains various helpers that are tailored to Pythons test suite and help smooth out common problems such as platform differences, resource consumption and cleanup, or warnings management. That module is not suitable for use outside of the standard library.

When you are adding tests to an existing test file, it is also recommended that you study the other tests in that file; it will teach you which precautions you have to take to make your tests robust and portable.


4.3. Benchmarks


Benchmarking is useful to test that a change does not degrade performance.

The Python Benchmark Suite has a collection of benchmarks for all Python implementations. Documentation about running the benchmarks is in the README.txt of the repo.


 




Table of Contents



4. Running & Writing Tests

4.1. Running

4.1.1. Unexpected Skips



4.2. Writing

4.3. Benchmarks



Sections



1. Getting Started

2. Where to Get Help

3. Lifecycle of a Pull Request

4. Running & Writing Tests

4.1. Running

4.1.1. Unexpected Skips



4.2. Writing

4.3. Benchmarks



5. Increase Test Coverage

6. Helping with Documentation

7. Documenting Python

8. Silence Warnings From the Test Suite

9. Fixing easy Issues (and Beyond)

10. Issue Tracking

11. Triaging an Issue

12. Following Pythons Development

13. Porting Python to a new platform

14. How to Become a Core Developer

15. Developer Log

16. Accepting Pull Requests

17. Development Cycle

18. Continuous Integration

19. Adding to the Stdlib

20. Changing the Python Language

21. Experts Index

22. gdb Support

23. Exploring CPythons Internals

24. Changing CPythons Grammar

25. Design of CPythons Compiler

26. Design of CPythons Garbage Collector

27. Updating standard library extension modules

28. Coverity Scan

29. Dynamic Analysis with Clang

30. Running a buildbot worker

31. Core Developer Motivations and Affiliations

32. Git Bootcamp and Cheat Sheet

33. Appendix: Topics

Previous topic


3. Lifecycle of a Pull Request

Next topic


5. Increase Test Coverage

This Page



Show Source  







Navigation



index

next |

previous |


Python »
  Python Developer's Guide »  
|  



© Copyright 2011-2020, Python Software Foundation.  
The Python Software Foundation is a non-profit corporation. Please donate.
 
Last updated on Nov 10, 2020.  Found a bug?
 Created using Sphinx 1.8.5.