neulab/docprompting-conala huggingface dataset:
run(result=None)  
Run the test, collecting the result into the TestResult object passed as result. If result is omitted or None, a temporary result object is created (by calling the defaultTestResult() method) and used. The result object is returned to run()’s caller. The same effect may be had by simply calling the TestCase instance.  Changed in version 3.3: Previous versions of run did not return the result. Neither did calling an instance.
setUp()  
Method called to prepare the test fixture. This is called immediately before calling the test method; other than AssertionError or SkipTest, any exception raised by this method will be considered an error rather than a test failure. The default implementation does nothing.
setUpClass()  
A class method called before tests in an individual class are run. setUpClass is called with the class as the only argument and must be decorated as a classmethod(): @classmethod
def setUpClass(cls):
    ...
 See Class and Module Fixtures for more details.  New in version 3.2.
shortDescription()  
Returns a description of the test, or None if no description has been provided. The default implementation of this method returns the first line of the test method’s docstring, if available, or None.  Changed in version 3.1: In 3.1 this was changed to add the test name to the short description even in the presence of a docstring. This caused compatibility issues with unittest extensions and adding the test name was moved to the TextTestResult in Python 3.2.
skipTest(reason)  
Calling this during a test method or setUp() skips the current test. See Skipping tests and expected failures for more information.  New in version 3.1.
subTest(msg=None, **params)  
Return a context manager which executes the enclosed code block as a subtest. msg and params are optional, arbitrary values which are displayed whenever a subtest fails, allowing you to identify them clearly. A test case can contain any number of subtest declarations, and they can be arbitrarily nested. See Distinguishing test iterations using subtests for more information.  New in version 3.4.
tearDown()  
Method called immediately after the test method has been called and the result recorded. This is called even if the test method raised an exception, so the implementation in subclasses may need to be particularly careful about checking internal state. Any exception, other than AssertionError or SkipTest, raised by this method will be considered an additional error rather than a test failure (thus increasing the total number of reported errors). This method will only be called if the setUp() succeeds, regardless of the outcome of the test method. The default implementation does nothing.
tearDownClass()  
A class method called after tests in an individual class have run. tearDownClass is called with the class as the only argument and must be decorated as a classmethod(): @classmethod
def tearDownClass(cls):
    ...
 See Class and Module Fixtures for more details.  New in version 3.2.
discover(start_dir, pattern='test*.py', top_level_dir=None)  
Find all the test modules by recursing into subdirectories from the specified start directory, and return a TestSuite object containing them. Only test files that match pattern will be loaded. (Using shell style pattern matching.) Only module names that are importable (i.e. are valid Python identifiers) will be loaded. All test modules must be importable from the top level of the project. If the start directory is not the top level directory then the top level directory must be specified separately. If importing a module fails, for example due to a syntax error, then this will be recorded as a single error and discovery will continue. If the import failure is due to SkipTest being raised, it will be recorded as a skip instead of an error. If a package (a directory containing a file named __init__.py) is found, the package will be checked for a load_tests function. If this exists then it will be called package.load_tests(loader, tests, pattern). Test discovery takes care to ensure that a package is only checked for tests once during an invocation, even if the load_tests function itself calls loader.discover. If load_tests exists then discovery does not recurse into the package, load_tests is responsible for loading all tests in the package. The pattern is deliberately not stored as a loader attribute so that packages can continue discovery themselves. top_level_dir is stored so load_tests does not need to pass this argument in to loader.discover(). start_dir can be a dotted module name as well as a directory.  New in version 3.2.   Changed in version 3.4: Modules that raise SkipTest on import are recorded as skips, not errors.   Changed in version 3.4: start_dir can be a namespace packages.   Changed in version 3.4: Paths are sorted before being imported so that execution order is the same even if the underlying file system’s ordering is not dependent on file name.   Changed in version 3.5: Found packages are now checked for load_tests regardless of whether their path matches pattern, because it is impossible for a package name to match the default pattern.
errors  
A list of the non-fatal errors encountered while loading tests. Not reset by the loader at any point. Fatal errors are signalled by the relevant a method raising an exception to the caller. Non-fatal errors are also indicated by a synthetic test that will raise the original error when run.  New in version 3.5.
getTestCaseNames(testCaseClass)  
Return a sorted sequence of method names found within testCaseClass; this should be a subclass of TestCase.
loadTestsFromModule(module, pattern=None)  
Return a suite of all test cases contained in the given module. This method searches module for classes derived from TestCase and creates an instance of the class for each test method defined for the class.  Note While using a hierarchy of TestCase-derived classes can be convenient in sharing fixtures and helper functions, defining test methods on base classes that are not intended to be instantiated directly does not play well with this method. Doing so, however, can be useful when the fixtures are different and defined in subclasses.  If a module provides a load_tests function it will be called to load the tests. This allows modules to customize test loading. This is the load_tests protocol. The pattern argument is passed as the third argument to load_tests.  Changed in version 3.2: Support for load_tests added.   Changed in version 3.5: The undocumented and unofficial use_load_tests default argument is deprecated and ignored, although it is still accepted for backward compatibility. The method also now accepts a keyword-only argument pattern which is passed to load_tests as the third argument.
loadTestsFromName(name, module=None)  
Return a suite of all test cases given a string specifier. The specifier name is a “dotted name” that may resolve either to a module, a test case class, a test method within a test case class, a TestSuite instance, or a callable object which returns a TestCase or TestSuite instance. These checks are applied in the order listed here; that is, a method on a possible test case class will be picked up as “a test method within a test case class”, rather than “a callable object”. For example, if you have a module SampleTests containing a TestCase-derived class SampleTestCase with three test methods (test_one(), test_two(), and test_three()), the specifier 'SampleTests.SampleTestCase' would cause this method to return a suite which will run all three test methods. Using the specifier 'SampleTests.SampleTestCase.test_two' would cause it to return a test suite which will run only the test_two() test method. The specifier can refer to modules and packages which have not been imported; they will be imported as a side-effect. The method optionally resolves name relative to the given module.  Changed in version 3.5: If an ImportError or AttributeError occurs while traversing name then a synthetic test that raises that error when run will be returned. These errors are included in the errors accumulated by self.errors.
loadTestsFromNames(names, module=None)  
Similar to loadTestsFromName(), but takes a sequence of names rather than a single name. The return value is a test suite which supports all the tests defined for each name.
loadTestsFromTestCase(testCaseClass)  
Return a suite of all test cases contained in the TestCase-derived testCaseClass. A test case instance is created for each method named by getTestCaseNames(). By default these are the method names beginning with test. If getTestCaseNames() returns no methods, but the runTest() method is implemented, a single test case is created for that method instead.
sortTestMethodsUsing  
Function to be used to compare method names when sorting them in getTestCaseNames() and all the loadTestsFrom*() methods.
suiteClass  
Callable object that constructs a test suite from a list of tests. No methods on the resulting object are needed. The default value is the TestSuite class. This affects all the loadTestsFrom*() methods.
testMethodPrefix  
String giving the prefix of method names which will be interpreted as test methods. The default value is 'test'. This affects getTestCaseNames() and all the loadTestsFrom*() methods.
testNamePatterns  
List of Unix shell-style wildcard test name patterns that test methods have to match to be included in test suites (see -v option). If this attribute is not None (the default), all test methods to be included in test suites must match one of the patterns in this list. Note that matches are always performed using fnmatch.fnmatchcase(), so unlike patterns passed to the -v option, simple substring patterns will have to be converted using * wildcards. This affects all the loadTestsFrom*() methods.  New in version 3.7.
addError(test, err)  
Called when the test case test raises an unexpected exception. err is a tuple of the form returned by sys.exc_info(): (type, value,
traceback). The default implementation appends a tuple (test, formatted_err) to the instance’s errors attribute, where formatted_err is a formatted traceback derived from err.
addExpectedFailure(test, err)  
Called when the test case test fails or errors, but was marked with the expectedFailure() decorator. The default implementation appends a tuple (test, formatted_err) to the instance’s expectedFailures attribute, where formatted_err is a formatted traceback derived from err.
addFailure(test, err)  
Called when the test case test signals a failure. err is a tuple of the form returned by sys.exc_info(): (type, value, traceback). The default implementation appends a tuple (test, formatted_err) to the instance’s failures attribute, where formatted_err is a formatted traceback derived from err.
addSkip(test, reason)  
Called when the test case test is skipped. reason is the reason the test gave for skipping. The default implementation appends a tuple (test, reason) to the instance’s skipped attribute.
addSubTest(test, subtest, outcome)  
Called when a subtest finishes. test is the test case corresponding to the test method. subtest is a custom TestCase instance describing the subtest. If outcome is None, the subtest succeeded. Otherwise, it failed with an exception where outcome is a tuple of the form returned by sys.exc_info(): (type, value, traceback). The default implementation does nothing when the outcome is a success, and records subtest failures as normal failures.  New in version 3.4.
addSuccess(test)  
Called when the test case test succeeds. The default implementation does nothing.
addUnexpectedSuccess(test)  
Called when the test case test was marked with the expectedFailure() decorator, but succeeded. The default implementation appends the test to the instance’s unexpectedSuccesses attribute.
buffer  
If set to true, sys.stdout and sys.stderr will be buffered in between startTest() and stopTest() being called. Collected output will only be echoed onto the real sys.stdout and sys.stderr if the test fails or errors. Any output is also attached to the failure / error message.  New in version 3.2.
errors  
A list containing 2-tuples of TestCase instances and strings holding formatted tracebacks. Each tuple represents a test which raised an unexpected exception.
expectedFailures  
A list containing 2-tuples of TestCase instances and strings holding formatted tracebacks. Each tuple represents an expected failure or error of the test case.
failfast  
If set to true stop() will be called on the first failure or error, halting the test run.  New in version 3.2.
failures  
A list containing 2-tuples of TestCase instances and strings holding formatted tracebacks. Each tuple represents a test where a failure was explicitly signalled using the TestCase.assert*() methods.
skipped  
A list containing 2-tuples of TestCase instances and strings holding the reason for skipping the test.  New in version 3.1.
startTestRun()  
Called once before any tests are executed.  New in version 3.1.
stop()  
This method can be called to signal that the set of tests being run should be aborted by setting the shouldStop attribute to True. TestRunner objects should respect this flag and return without running any additional tests. For example, this feature is used by the TextTestRunner class to stop the test framework when the user signals an interrupt from the keyboard. Interactive tools which provide TestRunner implementations can use this in a similar manner.
stopTest(test)  
Called after the test case test has been executed, regardless of the outcome.
stopTestRun()  
Called once after all tests are executed.  New in version 3.1.
tb_locals  
If set to true then local variables will be shown in tracebacks.  New in version 3.5.
unexpectedSuccesses  
A list containing TestCase instances that were marked as expected failures, but succeeded.
wasSuccessful()  
Return True if all tests run so far have passed, otherwise returns False.  Changed in version 3.4: Returns False if there were any unexpectedSuccesses from tests marked with the expectedFailure() decorator.
class unittest.TestSuite(tests=())  
This class represents an aggregation of individual test cases and test suites. The class presents the interface needed by the test runner to allow it to be run as any other test case. Running a TestSuite instance is the same as iterating over the suite, running each test individually. If tests is given, it must be an iterable of individual test cases or other test suites that will be used to build the suite initially. Additional methods are provided to add test cases and suites to the collection later on. TestSuite objects behave much like TestCase objects, except they do not actually implement a test. Instead, they are used to aggregate tests into groups of tests that should be run together. Some additional methods are available to add tests to TestSuite instances:  
addTest(test)  
Add a TestCase or TestSuite to the suite. 
  
addTests(tests)  
Add all the tests from an iterable of TestCase and TestSuite instances to this test suite. This is equivalent to iterating over tests, calling addTest() for each element. 
 TestSuite shares the following methods with TestCase:  
run(result)  
Run the tests associated with this suite, collecting the result into the test result object passed as result. Note that unlike TestCase.run(), TestSuite.run() requires the result object to be passed in. 
  
debug()  
Run the tests associated with this suite without collecting the result. This allows exceptions raised by the test to be propagated to the caller and can be used to support running tests under a debugger. 
  
countTestCases()  
Return the number of tests represented by this test object, including all individual tests and sub-suites. 
  
__iter__()  
Tests grouped by a TestSuite are always accessed by iteration. Subclasses can lazily provide tests by overriding __iter__(). Note that this method may be called several times on a single suite (for example when counting tests or comparing for equality) so the tests returned by repeated iterations before TestSuite.run() must be the same for each call iteration. After TestSuite.run(), callers should not rely on the tests returned by this method unless the caller uses a subclass that overrides TestSuite._removeTestAtIndex() to preserve test references.  Changed in version 3.2: In earlier versions the TestSuite accessed tests directly rather than through iteration, so overriding __iter__() wasn’t sufficient for providing tests.   Changed in version 3.4: In earlier versions the TestSuite held references to each TestCase after TestSuite.run(). Subclasses can restore that behavior by overriding TestSuite._removeTestAtIndex().  
 In the typical usage of a TestSuite object, the run() method is invoked by a TestRunner rather than by the end-user test harness.
addTests(tests)  
Add all the tests from an iterable of TestCase and TestSuite instances to this test suite. This is equivalent to iterating over tests, calling addTest() for each element.
countTestCases()  
Return the number of tests represented by this test object, including all individual tests and sub-suites.
debug()  
Run the tests associated with this suite without collecting the result. This allows exceptions raised by the test to be propagated to the caller and can be used to support running tests under a debugger.
run(result)  
Run the tests associated with this suite, collecting the result into the test result object passed as result. Note that unlike TestCase.run(), TestSuite.run() requires the result object to be passed in.
__iter__()  
Tests grouped by a TestSuite are always accessed by iteration. Subclasses can lazily provide tests by overriding __iter__(). Note that this method may be called several times on a single suite (for example when counting tests or comparing for equality) so the tests returned by repeated iterations before TestSuite.run() must be the same for each call iteration. After TestSuite.run(), callers should not rely on the tests returned by this method unless the caller uses a subclass that overrides TestSuite._removeTestAtIndex() to preserve test references.  Changed in version 3.2: In earlier versions the TestSuite accessed tests directly rather than through iteration, so overriding __iter__() wasn’t sufficient for providing tests.   Changed in version 3.4: In earlier versions the TestSuite held references to each TestCase after TestSuite.run(). Subclasses can restore that behavior by overriding TestSuite._removeTestAtIndex().
class unittest.TextTestResult(stream, descriptions, verbosity)  
A concrete implementation of TestResult used by the TextTestRunner.  New in version 3.2: This class was previously named _TextTestResult. The old name still exists as an alias but is deprecated.
class unittest.TextTestRunner(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False)  
A basic test runner implementation that outputs results to a stream. If stream is None, the default, sys.stderr is used as the output stream. This class has a few configurable parameters, but is essentially very simple. Graphical applications which run test suites should provide alternate implementations. Such implementations should accept **kwargs as the interface to construct runners changes when features are added to unittest. By default this runner shows DeprecationWarning, PendingDeprecationWarning, ResourceWarning and ImportWarning even if they are ignored by default. Deprecation warnings caused by deprecated unittest methods are also special-cased and, when the warning filters are 'default' or 'always', they will appear only once per-module, in order to avoid too many warning messages. This behavior can be overridden using Python’s -Wd or -Wa options (see Warning control) and leaving warnings to None.  Changed in version 3.2: Added the warnings argument.   Changed in version 3.2: The default stream is set to sys.stderr at instantiation time rather than import time.   Changed in version 3.5: Added the tb_locals parameter.   
_makeResult()  
This method returns the instance of TestResult used by run(). It is not intended to be called directly, but can be overridden in subclasses to provide a custom TestResult. _makeResult() instantiates the class or callable passed in the TextTestRunner constructor as the resultclass argument. It defaults to TextTestResult if no resultclass is provided. The result class is instantiated with the following arguments: stream, descriptions, verbosity
 
  
run(test)  
This method is the main public interface to the TextTestRunner. This method takes a TestSuite or TestCase instance. A TestResult is created by calling _makeResult() and the test(s) are run and the results printed to stdout.
run(test)  
This method is the main public interface to the TextTestRunner. This method takes a TestSuite or TestCase instance. A TestResult is created by calling _makeResult() and the test(s) are run and the results printed to stdout.
_makeResult()  
This method returns the instance of TestResult used by run(). It is not intended to be called directly, but can be overridden in subclasses to provide a custom TestResult. _makeResult() instantiates the class or callable passed in the TextTestRunner constructor as the resultclass argument. It defaults to TextTestResult if no resultclass is provided. The result class is instantiated with the following arguments: stream, descriptions, verbosity
urllib — URL handling modules Source code: Lib/urllib/ urllib is a package that collects several modules for working with URLs:  
urllib.request for opening and reading URLs 
urllib.error containing the exceptions raised by urllib.request
 
urllib.parse for parsing URLs 
urllib.robotparser for parsing robots.txt files
urllib.error — Exception classes raised by urllib.request Source code: Lib/urllib/error.py The urllib.error module defines the exception classes for exceptions raised by urllib.request. The base exception class is URLError. The following exceptions are raised by urllib.error as appropriate:  
exception urllib.error.URLError  
The handlers raise this exception (or derived exceptions) when they run into a problem. It is a subclass of OSError.  
reason  
The reason for this error. It can be a message string or another exception instance. 
  Changed in version 3.3: URLError has been made a subclass of OSError instead of IOError.  
  
exception urllib.error.HTTPError  
Though being an exception (a subclass of URLError), an HTTPError can also function as a non-exceptional file-like return value (the same thing that urlopen() returns). This is useful when handling exotic HTTP errors, such as requests for authentication.  
code  
An HTTP status code as defined in RFC 2616. This numeric value corresponds to a value found in the dictionary of codes as found in http.server.BaseHTTPRequestHandler.responses. 
  
reason  
This is usually a string explaining the reason for this error. 
  
headers  
The HTTP response headers for the HTTP request that caused the HTTPError.  New in version 3.4.  
 
  
exception urllib.error.ContentTooShortError(msg, content)  
This exception is raised when the urlretrieve() function detects that the amount of the downloaded data is less than the expected amount (given by the Content-Length header). The content attribute stores the downloaded (and supposedly truncated) data.
exception urllib.error.ContentTooShortError(msg, content)  
This exception is raised when the urlretrieve() function detects that the amount of the downloaded data is less than the expected amount (given by the Content-Length header). The content attribute stores the downloaded (and supposedly truncated) data.