Introduction and Analysis of the Python test suite

The Python test suite has the most abundant and powerful class libraries in the scripting language and is sufficient to support most daily applications. Its name comes from a comedy. Perhaps those who initially designed the Language Python did not expect that today Python will be widely used in industry and scientific research.

In a long document, a Python prompt >>> consisting of three greater than signs is a very obvious sign, indicating what should happen on the Python prompt. As you can see in the first article in this series, this can appear in a separate text file as a document:

 
 

  
  
Doctest for truth and falsehood  
  
  
-------------------------------  
  
  
 
  
  
The truth values in Python, named "True" and "False",  
  
  
are equivalent to the Boolean numbers one and zero.  
  
  
 
  
  
>>> True == 1  
  
  
True  
  
  
>>> False == 0  
  
  
True 
 
 

This description can also appear in the docstring of the module, class, or function in the source code:

 
 

  
  
def count_vowels(s):  
  
  
    """Count the number of vowels in a string.  
  
  
 
  
  
    >>> count_vowels('aardvark')  
  
  
    3  
  
  
    >>> count_vowels('THX')  
  
  
    0  
  
  
 
  
  
    """  
  
  
    return len( c for c in s if c in 'aeiou') 
 
 

When these tests appear in a text file, such as the first example), the file is called docfile. When they appear in docstring in Python source code, such as the second example), they are called doctest. Because docfile and doctest are common methods for writing documents used for testing, and this can also indicate when documents are outdated), py. test and nose support them directly.

Zope. testing users must use the DocTestSuite class in the standard doctest module to manually create Python test cases for each file ). Like the rules used to search for test Modules, The py. test Framework supports doctest in a fixed process and cannot be configured. This standardizes projects, but limits the flexibility of projects.

If its Python test suite is enabled, it will be included in the document string of all Python modules, including the module name that does not contain the test module. search for doctest in all text files ending with the txt extension.

If the-p restdoc plug-in is enabled, not only does the execution of all doctest and py. test in the. txt file require that each. txt file in the project be a valid Restructured Text file. If they cause parsing errors, py. test issues a warning. You can also use the command line option to let the plug-in check the specified URL in the document, and then generate the HTML version of each. txt text file.

Doctest-tests is the option with minimal interference. It only requires nose to search for doctest in the docstring of the tested module that has been checked. The with-doctest option has a greater impact. It requires nose to search for all modules whose general modules are not tests but contain general code), find and run doctest in their docstring.

Finally, -- doctest-extension allows most developers I know to specify the file extension. txt,. rst, or. doctest ). This requires nose to read all text files with the specified extension in the project, run and check all Python Test suites it finds.

Although py. test and nose have similar feature sets in this respect, I prefer the nose method. I like to use a non-standard. rst extension for all Restructured Text files so that the Text editor can recognize them and apply special syntaxes to them for highlighting.

1. Introduction to Python system files
2. How to correctly use Python Functions
3. Detailed introduction and analysis of Python build tools
4. Advantages of Python in PythonAndroid
5. How to Use the Python module to parse the configuration file?