/usr/share/pyshared/DTest-0.4.0.egg-info is in python-dtest 0.4.0-0ubuntu2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 | Metadata-Version: 1.1
Name: DTest
Version: 0.4.0
Summary: Dependency-based Threaded Test Framework
Home-page: http://github.com/klmitch/dtest
Author: Kevin L. Mitchell
Author-email: kevin.mitchell@rackspace.com
License: LICENSE.txt
Description: ========================================
Dependency-based Threaded Test Framework
========================================
The DTest framework is a testing framework, similar to the standard
``unittest`` package provided by Python. The value-add for DTest,
however, is that test execution is threaded, through use of the
``eventlet`` package. The DTest package also provides the concept of
"dependencies" between tests and test fixtures--thus the "D" in
"DTest"--which ensure that tests don't run until the matching set up
test fixtures have completed, and that the tear down test fixtures
don't run until all the associated tests have completed. Dependencies
may also be used to ensure that tests requiring the availability of
certain functionality don't run if the tests of that specific
functionality fail.
Writing Tests
=============
The simplest test programs are simple functions with names beginning
with "test," located in Python source files whose names also begin
with "test." It is not even necessary to import any portion of the
DTest framework. If tests are collected in classes, however, or if
use of the more advanced features of DTest is desired, a simple ``from
dtest import *`` is necessary. This makes available the ``DTestCase``
class--which should be extended by all classes containing tests--as
well as such decorators as ``@skip`` and ``@nottest``.
Tests may be performed using the standard Python ``assert`` statement;
however, a number of utility routines are available in the
``dtest.util`` module (also safe for ``import *``). Many of these
utility routines have names similar to methods of
``unittest.TestCase``--e.g., ``dtest.util.assert_dict_equal()`` is
analogous to ``unittest.TestCase.assertDictEqual()``.
Test Fixtures
=============
The DTest framework supports test fixtures--set up and tear down
functions--at the class, module, and package level. Package-level
fixtures consist of functions named ``setUp()`` and ``tearDown()``
contained within "__init__.py" files; similarly, module-level fixtures
consist of functions samed ``setUp()`` and ``tearDown()`` within
modules containing test functions and classes of test methods. At the
class level, classes may contain ``setUpClass()`` and
``tearDownClass()`` class methods (or static methods), which may
perform set up and tear down for each class. In all cases, the
``setUp()`` functions and the ``setUpClass()`` method are executed
before any of the tests within the same scope; similarly, after all
the tests at a given scope have executed, the corresponding
``tearDownClass()`` method and ``tearDown()`` functions are executed.
The DTest framework also supports per-test ``setUp()`` and
``tearDown()`` functions or methods, which are run before and after
each associated test. For classes containing tests, each test
automatically has the setUp() and tearDown() methods of the class
associated with them; however, for all tests, these fixtures can be
explicitly set (or overridden from the class default). Consider the
following example::
@istest
def test_something():
# Test something here
pass
@test_something.setUp
def something_setup():
# Get everything set up ready to go...
pass
@test_something.tearDown
def something_teardown():
# Clean up after ourselves
pass
In this example, a DTest decorator (other than ``@nottest``) is
necessary preceding ``test_something()``; here we used ``@istest``,
but any other available DTest decorator could be used here. This
makes the ``@test_something.setUp`` and ``@test_something.tearDown``
decorators available. (For something analogous in the standard
Python, check out the built-in ``@property`` decorator.)
Running Tests
=============
Running tests using the DTest framework is fairly straight-forward. A
script called ``run-dtests`` is available. By default, the current
directory is scanned for all modules or packages whose names begin
with "test"; the search also recurses down through all packages. (A
"package" is defined as a directory containing "__init__.py".) Once
all tests are discovered, they are then executed, and the results of
the tests emitted to standard output.
Several command-line options are available for controlling the
behavior of ``run-dtests``. For instance, the "--no-skip" option will
cause ``run-dtests`` to run all tests, even those decorated with the
``@skip`` decorator, and the "-d" option causes ``run-dtests`` to
search a specific directory, rather than the current directory. For a
full list of options, use the "-h" or "--help" option.
Running ``run-dtests`` from the command line is not the only way to
run tests, however. The ``run-dtests`` script is a very simple script
that parses command-line options (using the ``OptionParser``
constructed by the ``dtest.optparser()`` function), converts those
options into a set of keyword arguments (using
``dtest.opts_to_args()``), then passes those keyword arguments to the
``dtest.main()`` function. Users can use these functions to build the
same functionality with user-specific extensions, such as providing an
alternate DTestOutput instance to control how test results are
displayed, or providing an alternate method for controlling which
tests are skipped. See the documentation strings for these functions
and classes for more information.
Platform: UNKNOWN
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Console
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: End Users/Desktop
Classifier: Intended Audience :: Information Technology
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Topic :: Software Development :: Testing
Requires: eventlet
|