`test` — Paquete de pruebas de regresión para Python¶

Nota

El paquete test está destinado solo para uso interno de Python. Está documentado para beneficio de los desarrolladores principales de Python. Se desaconseja el uso de este paquete fuera de la biblioteca estándar de Python, ya que el código mencionado aquí puede cambiar o eliminarse sin previo aviso entre versiones de Python.

El paquete test contiene todas las pruebas de regresión para Python, así como los módulos test.support y test.regrtest. Se utiliza test.support para mejorar sus pruebas, mientras que test.regrtest maneja el conjunto de pruebas.

Cada módulo en el paquete test cuyo nombre comienza con test_ es un conjunto de pruebas para un módulo o característica específica. Todas las pruebas nuevas deben escribirse usando el módulo unittest o doctest. Algunas pruebas anteriores se escriben utilizando un estilo de prueba «tradicional» que compara la salida impresa con sys.stdout; este estilo de prueba se considera obsoleto.

Ver también

Módulo unittest: Escritura de pruebas de regresión de PyUnit.
Módulo doctest: Pruebas integradas en cadenas de caracteres de documentación.

Escritura de pruebas unitarias para el paquete `test`¶

Se prefiere que las pruebas que utilizan el módulo unittest sigan algunas pautas. Una es nombrar el módulo de prueba comenzándolo con test_ y terminarlo con el nombre del módulo que se está probando. Los métodos de prueba en el módulo de prueba deben comenzar con test_ y terminar con una descripción de lo que el método está probando. Esto es necesario para que el controlador de prueba reconozca los métodos como métodos de prueba. Por lo tanto, no se debe incluir una cadena de caracteres de documentación para el método. Se debe usar un comentario (como # Tests function returns only True or False) para proporcionar documentación para los métodos de prueba. Esto se hace porque las cadenas de documentación se imprimen si existen y, por lo tanto, no se indica qué prueba se está ejecutando.

A menudo se usa una plantilla básica:

import unittest
from test import support

class MyTestCase1(unittest.TestCase):

    # Only use setUp() and tearDown() if necessary

    def setUp(self):
        ... code to execute in preparation for tests ...

    def tearDown(self):
        ... code to execute to clean up after tests ...

    def test_feature_one(self):
        # Test feature one.
        ... testing code ...

    def test_feature_two(self):
        # Test feature two.
        ... testing code ...

    ... more test methods ...

class MyTestCase2(unittest.TestCase):
    ... same structure as MyTestCase1 ...

... more test classes ...

if __name__ == '__main__':
    unittest.main()

Este patrón de código permite que el conjunto de pruebas sea ejecutado por test.regrtest, como un script que admite la CLI unittest, o mediante la CLI python -m unittest.

El objetivo de las pruebas de regresión es intentar romper el código. Esto lleva a algunas pautas a seguir:

El conjunto de pruebas debe ejercer todas las clases, funciones y constantes. Esto incluye no solo la API externa que se presentará al mundo exterior sino también el código «privado».
Se prefiere la prueba de caja blanca (examinar el código que se prueba cuando se escriben las pruebas). Las pruebas de caja negra (probar solo la interfaz de usuario publicada) no son lo suficientemente completas como para garantizar que se prueben todos los casos límite y límite.
Asegúrese de que todos los valores posibles son probados, incluidos los no válidos. Esto asegura que no solo todos los valores válidos sean aceptables, sino que los valores incorrectos se manejen correctamente.
Agote tantas rutas de código cómo sea posible. Pruebe donde se produce la ramificación y, por lo tanto, adapte la entrada para asegurarse de que se toman muchas rutas diferentes a través del código.
Añada una prueba explícita para cualquier error descubierto para el código probado. Esto asegurará que el error no vuelva a aparecer si el código se cambia en el futuro.
Asegúrese de limpiar después de sus pruebas (así como cerrar y eliminar todos los archivos temporales).
Si una prueba depende de una condición específica del sistema operativo, verifique que la condición ya existe antes de intentar la prueba.
Importe la menor cantidad de módulos posible y hágalo lo antes posible. Esto minimiza las dependencias externas de las pruebas y también minimiza el posible comportamiento anómalo de los efectos secundarios de importar un módulo.
Intente maximizar la reutilización del código. En ocasiones, las pruebas variarán en algo tan pequeño como qué tipo de entrada se utiliza. Minimice la duplicación de código usando como clase base una clase de prueba básica con una clase que especifique la entrada:
```
class TestFuncAcceptsSequencesMixin:

    func = mySuperWhammyFunction

    def test_func(self):
        self.func(self.arg)

class AcceptLists(TestFuncAcceptsSequencesMixin, unittest.TestCase):
    arg = [1, 2, 3]

class AcceptStrings(TestFuncAcceptsSequencesMixin, unittest.TestCase):
    arg = 'abc'

class AcceptTuples(TestFuncAcceptsSequencesMixin, unittest.TestCase):
    arg = (1, 2, 3)
```
Cuando use este patrón, recuerde que todas las clases que heredan unittest.TestCase se ejecutan como pruebas. La clase Mixin en el ejemplo anterior no tiene ningún dato y, por lo tanto, no se puede ejecutar solo, por lo tanto, no hereda de unittest.TestCase.

Ver también

Desarrollo dirigido por pruebas (Test Driven Development): Un libro de Kent Beck sobre pruebas de escritura antes del código.

Ejecución de pruebas utilizando la interfaz de línea de comandos¶

El paquete test puede ejecutarse como un script para controlar el conjunto de pruebas de regresión de Python, gracias a la opción -m : python -m test. Internamente, se utiliza test.regrtest; la llamada python -m test.regrtest utilizada en versiones anteriores de Python todavía funciona. Ejecuta el script por sí mismo automáticamente y comienza a ejecutar todas las pruebas de regresión en el paquete test.regrtest. Lo hace buscando todos los módulos en el paquete cuyo nombre comienza con ``test_`, importándolos y ejecutando la función test_main() si está presente o cargando las pruebas a través de unittest.TestLoader.loadTestsFromModule si test_main no existe. Los nombres de las pruebas a ejecutar también se pueden pasar al script. La especificación de una prueba de regresión única (python -m test test_spam) minimizará la salida y solo imprimirá si la prueba pasó o no.

Ejecutando test directamente permite establecer qué recursos están disponibles para que se usen las pruebas. Para ello, use la opción de línea de comandos -u. Al especificar all como el valor para la opción -u se habilitan todos los recursos posibles: python -m test -uall. Si se desean todos los recursos menos uno (un caso más común), se puede enumerar una lista de recursos separados por comas que no se desean después de all. El comando python -m test -uall,-audio,-largefile ejecutará test con todos los recursos excepto los recursos audio y largefile. Para obtener una lista de todos los recursos y más opciones de línea de comandos, ejecute python -m test -h.

Algunas otras formas de ejecutar las pruebas de regresión dependen de en qué plataforma se ejecuten las pruebas. En Unix, puede ejecutar make test en el directorio de nivel superior donde se construyó Python. En Windows, ejecutar rt.bat desde su directorio PCbuild ejecutará todas las pruebas de regresión.

`test.support` — Utilidades para el conjunto de pruebas de Python¶

El módulo test.support proporciona soporte para el conjunto de pruebas de regresión de Python.

Nota

test.support no es un módulo público. Está documentado aquí para ayudar a los desarrolladores de Python a escribir pruebas. La API de este módulo está sujeta a cambios sin problemas de compatibilidad con versiones anteriores entre versiones.

Este módulo define las siguientes excepciones:

exception test.support.TestFailed¶: Excepción que se lanzará cuando una prueba falle. Esto está en desuso a favor de pruebas basadas en unittesty en métodos de aserción unittest.TestCase

exception test.support.ResourceDenied¶: La subclase de unittest.SkipTest. Se lanza cuando un recurso (como una conexión de red) no está disponible. Lanzado por la función requires().

El módulo test.support define las siguientes constantes:

test.support.verbose¶: True cuando la salida detallada está habilitada. Debe verificarse cuando se desea información más detallada sobre una prueba en ejecución. verbose está establecido por test.regrtest.

test.support.is_jython¶: True si el intérprete en ejecución es Jython.

test.support.is_android¶: True si el sistema es Android.

test.support.unix_shell¶: Ruta del shell si no está en Windows; de otra manera None.

test.support.FS_NONASCII¶: Un carácter no codificable ASCII codificable por os.fsencode().

test.support.TESTFN¶: Establecido a un nombre que sea seguro de usar como nombre de un archivo temporal. Cualquier archivo temporal que se cree debe cerrarse y desvincularse (eliminarse).

test.support.TESTFN_UNICODE¶: Establecido un nombre que no sea ASCII para un archivo temporal.

test.support.TESTFN_ENCODING¶: Establecido en sys.getfilesystemencoding().

test.support.TESTFN_UNENCODABLE¶: Establecido un nombre de archivo (tipo str) que no se pueda codificar mediante la codificación del sistema de archivos en modo estricto. Puede ser None si no es posible generar dicho nombre de archivo.

test.support.TESTFN_UNDECODABLE¶: Establecido un nombre de archivo (tipo de bytes) que no pueda descodificarse mediante la codificación del sistema de archivos en modo estricto. Puede ser None si no es posible generar dicho nombre de archivo.

test.support.TESTFN_NONASCII¶: Establecido un nombre de archivo que contiene el carácter FS_NONASCII.

test.support.IPV6_ENABLED¶: Establecido True si IPV6 está habilitado en este host, de lo contrario False.

test.support.SAVEDCWD¶: Establecido os.getcwd().

test.support.PGO¶: Establecido cuando se pueden omitir las pruebas cuando no son útiles para PGO.

test.support.PIPE_MAX_SIZE¶: Una constante que probablemente sea más grande que el tamaño del búfer de la tubería (pipe) del sistema operativo subyacente, para bloquear las escrituras.

test.support.SOCK_MAX_SIZE¶: Una constante que probablemente sea más grande que el tamaño del búfer del socket del sistema operativo subyacente para bloquear las escrituras.

test.support.TEST_SUPPORT_DIR¶: Establecido en el directorio de nivel superior que contiene test.support.

test.support.TEST_HOME_DIR¶: Establecido en el directorio de nivel superior para el paquete de prueba.

test.support.TEST_DATA_DIR¶: Establecido en el directorio data dentro del paquete de prueba.

test.support.MAX_Py_ssize_t¶: Establecido sys.maxsize para pruebas de gran memoria.

test.support.max_memuse¶: Establecido por set_memlimit() como límite de memoria para pruebas de memoria grande. Limitado por MAX_Py_ssize_t.

test.support.real_max_memuse¶: Establecido por set_memlimit() como límite de memoria para pruebas de memoria grande. No limitado por MAX_Py_ssize_t.

test.support.MISSING_C_DOCSTRINGS¶: Retorna True si se ejecuta en CPython, no en Windows, y la configuración no está configurada con WITH_DOC_STRINGS.

test.support.HAVE_DOCSTRINGS¶: Verifica la presencia de cadenas de documentos (docstrings).

test.support.TEST_HTTP_URL¶: Define la URL de un servidor HTTP dedicado para las pruebas de red.

test.support.ALWAYS_EQ¶: Objeto que es igual a cualquier cosa. Se utiliza para probar la comparación de tipos mixtos.

test.support.LARGEST¶: Objeto que es mayor que cualquier cosa (excepto a sí mismo). Se utiliza para probar la comparación de tipos mixtos.

test.support.SMALLEST¶: Objeto que es menor que cualquier cosa (excepto él mismo). Se utiliza para probar la comparación de tipos mixtos.

El módulo test.support define las siguientes funciones:

test.support.forget(module_name)¶: Elimina el módulo llamado module_name de sys.modules y elimina los archivos compilados por bytes del módulo.

test.support.unload(name)¶: Elimina name de sys.modules.

test.support.unlink(filename)¶: Llama a os.unlink() en filename. En plataformas Windows, esto está envuelto con un ciclo de espera que verifica la existencia del archivo.

test.support.rmdir(filename)¶: Llama a os.rmdir() en filename. En las plataformas Windows, esto está envuelto con un ciclo de espera que verifica la existencia del archivo.

test.support.rmtree(path)¶: Llama a shutil.rmtree() en path o os.lstat() y os.rmdir() para eliminar una ruta y su contenido. En las plataformas Windows, esto está envuelto con un ciclo de espera que verifica la existencia de los archivos.

test.support.make_legacy_pyc(source)¶: Mueve un archivo pyc de PEP 3147/PEP 488 a su ubicación heredada y retorna la ruta del sistema de archivos al archivo de pyc heredado. El valor de origen es la ruta del sistema de archivos al archivo fuente. No es necesario que exista, sin embargo, debe existir el archivo PEP 3147/488 pyc.

test.support.is_resource_enabled(resource)¶: Retorna True si resource está habilitado y disponible. La lista de recursos disponibles solo se establece cuando test.regrtest está ejecutando las pruebas.

test.support.python_is_optimized()¶: Retorna True si Python no fue construido con -O0 o -Og.

test.support.with_pymalloc()¶: Retorna _testcapi.WITH_PYMALLOC.

test.support.requires(resource, msg=None)¶: Lanza ResourceDenied si resource no está disponible. msg es el argumento para ResourceDenied si se lanza. Siempre retorna True si es invocado por una función cuyo __name__ es '__main__'. Se usa cuando se ejecutan pruebas por test.regrtest.

test.support.system_must_validate_cert(f)¶: Lanza unittest.SkipTest en fallos de validación de certificación TLS.

test.support.sortdict(dict)¶: Retorna una representación del diccionario con las claves ordenadas.

test.support.findfile(filename, subdir=None)¶

Retorna la ruta al archivo llamado filename. Si no se encuentra ninguna coincidencia, se retorna filename. Esto no equivale a un fallo, ya que podría ser la ruta al archivo.

La configuración subdir indica una ruta relativa a utilizar para encontrar el archivo en lugar de buscar directamente en los directorios de ruta.

test.support.create_empty_file(filename)¶: Crea un archivo vacío con filename. Si ya existe, truncarlo.

test.support.fd_count()¶: Cuenta el número de descriptores de archivo abiertos.

test.support.match_test(test)¶: Hace coincidir test con los patrones establecidos en set_match_tests().

test.support.set_match_tests(patterns)¶: Define una prueba de coincidencia con una expresión regular patterns.

test.support.run_unittest(*classes)¶

Ejecuta subclases unittest.TestCase pasadas a la función. La función escanea las clases en busca de métodos que comiencen con el prefijo test_ y ejecuta las pruebas individualmente.

También está permitido pasar cadenas de caracteres como parámetros; Estas deberían ser claves en sys.modules. Cada módulo asociado será escaneado por unittest.TestLoader.loadTestsFromModule(). Esto generalmente se ve en la siguiente función test_main():

def test_main():
    support.run_unittest(__name__)

Esto ejecutará todas las pruebas definidas en el módulo nombrado.

test.support.run_doctest(module, verbosity=None, optionflags=0)¶

Ejecuta doctest.testmod() en module dado. Retorna (failure_count, test_count).

Si verbosity es None, la doctest.testmod() se ejecuta con verbosity establecido en verbose. De lo contrario, se ejecuta con verbosidad establecida en None. optionflags se pasa como optionflags to doctest.testmod().

test.support.setswitchinterval(interval)¶: Establecido sys.setswitchinterval() en el intervalo dado. Define un intervalo mínimo para los sistemas Android para evitar que el sistema se cuelgue.

test.support.check_impl_detail(**guards)¶

Usa esta comprobación para proteger las pruebas específicas de implementación de CPython o para ejecutarlas solo en las implementaciones protegidas por los argumentos:

check_impl_detail()               # Only on CPython (default).
check_impl_detail(jython=True)    # Only on Jython.
check_impl_detail(cpython=False)  # Everywhere except CPython.

test.support.check_warnings(*filters, quiet=True)¶

Un envoltorio de conveniencia para warnings.catch_warnings() que hace que sea más fácil probar que una advertencia se lanzó correctamente. Es aproximadamente equivalente a llamar a warnings.catch_warnings(record=True) con warnings.simplefilter() establecido en always y con la opción de validar automáticamente los resultados que se registran.

check_warnings acepta 2 tuplas de la forma ("mensaje regexp", WarningCategory) como argumentos posicionales. Si se proporcionan uno o más filters, o si el argumento opcional de palabra clave quiet es False, se verifica para asegurarse de que las advertencias sean las esperadas: cada filtro especificado debe coincidir con al menos una de las advertencias lanzadas por el código adjunto o la prueba falla, y si se lanzan advertencias que no coinciden con ninguno de los filtros especificados, la prueba falla. Para deshabilitar la primera de estas comprobaciones, configure quiet en True.

Si no se especifican argumentos, el valor predeterminado es:

check_warnings(("", Warning), quiet=True)

En este caso, se capturan todas las advertencias y no se lanzaran errores.

En la entrada al administrador de contexto, se retorna una instancia de WarningRecorder. La lista de advertencias subyacentes de catch_warnings() está disponible a través del atributo warnings del objeto del registrador. Como conveniencia, también se puede acceder directamente a los atributos del objeto que representa la advertencia más reciente a través del objeto grabador (vea el ejemplo a continuación). Si no se ha lanzado ninguna advertencia, cualquiera de los atributos que de otro modo se esperarían en un objeto que representa una advertencia retornará None.

El objeto grabador (recorder object) también tiene un método reset(), que borra la lista de advertencias.

El administrador de contexto está diseñado para usarse así:

with check_warnings(("assertion is always true", SyntaxWarning),
                    ("", UserWarning)):
    exec('assert(False, "Hey!")')
    warnings.warn(UserWarning("Hide me!"))

En este caso, si no se generó ninguna advertencia, o si surgió alguna otra advertencia, check_warnings() lanzaría un error.

Cuando una prueba necesita analizar más profundamente las advertencias, en lugar de simplemente verificar si ocurrieron o no, se puede usar un código como este:

with check_warnings(quiet=True) as w:
    warnings.warn("foo")
    assert str(w.args[0]) == "foo"
    warnings.warn("bar")
    assert str(w.args[0]) == "bar"
    assert str(w.warnings[0].args[0]) == "foo"
    assert str(w.warnings[1].args[0]) == "bar"
    w.reset()
    assert len(w.warnings) == 0

Aquí se capturarán todas las advertencias, y el código de prueba prueba las advertencias capturadas directamente.

Distinto en la versión 3.2: Nuevos argumentos opcionales filters y quiet.

test.support.check_no_resource_warning(testcase)¶: Gestor de contexto para comprobar que no se ha lanzado un ResourceWarning . Debe eliminar el objeto que puede emitir ResourceWarning antes del final del administrador de contexto.

test.support.set_memlimit(limit)¶: Establece los valores para max_memuse y real_max_memuse para pruebas de memoria grande.

test.support.record_original_stdout(stdout)¶: Almacene el valor de stdout. Está destinado a mantener el stdout en el momento en que comenzó el regrtest.

test.support.get_original_stdout()¶: Retorna el stdout original establecido por record_original_stdout() o sys.stdout si no está configurado.

test.support.strip_python_strerr(stderr)¶: Elimine el stderr de un proceso de Python de la salida de depuración potencial emitida por el intérprete. Esto normalmente se ejecutará en el resultado de subprocess.Popen.communicate().

test.support.args_from_interpreter_flags()¶: Retorna una lista de argumentos de línea de comandos que reproducen la configuración actual en sys.flags y sys.warnoptions.

test.support.optim_args_from_interpreter_flags()¶: Retorna una lista de argumentos de línea de comandos que reproducen la configuración de optimización actual en sys.flags.

test.support.captured_stdin()¶

test.support.captured_stdout()¶

test.support.captured_stderr()¶

Un administrador de contexto que reemplaza temporalmente la secuencia nombrada con un objeto io.StringIO.

Ejemplo de uso con flujos de salida:

with captured_stdout() as stdout, captured_stderr() as stderr:
    print("hello")
    print("error", file=sys.stderr)
assert stdout.getvalue() == "hello\n"
assert stderr.getvalue() == "error\n"

Ejemplo de uso con flujo de entrada:

with captured_stdin() as stdin:
    stdin.write('hello\n')
    stdin.seek(0)
    # call test code that consumes from sys.stdin
    captured = input()
self.assertEqual(captured, "hello")

test.support.temp_dir(path=None, quiet=False)¶

Un administrador de contexto que crea un directorio temporal en path y produce el directorio.

Si path es None, el directorio temporal se crea usando tempfile.mkdtemp(). Si quiet es False, el administrador de contexto lanza una excepción en caso de error. De lo contrario, si se especifica path y no se puede crear, solo se emite una advertencia.

test.support.change_cwd(path, quiet=False)¶

Un administrador de contexto que cambia temporalmente el directorio de trabajo actual a path y produce el directorio.

Si quiet es False, el administrador de contexto lanza una excepción en caso de error. De lo contrario, solo emite una advertencia y mantiene el directorio de trabajo actual igual.

test.support.temp_cwd(name='tempcwd', quiet=False)¶

Un administrador de contexto que crea temporalmente un nuevo directorio y cambia el directorio de trabajo actual (CWD).

El administrador de contexto crea un directorio temporal en el directorio actual con el nombre name antes de cambiar temporalmente el directorio de trabajo actual. Si name es None , el directorio temporal se crea usando tempfile.mkdtemp().

Si quiet es False y no es posible crear o cambiar el CWD, se lanza un error. De lo contrario, solo se lanza una advertencia y se utiliza el CWD original.

test.support.temp_umask(umask)¶: Un administrador de contexto que establece temporalmente el proceso umask.

test.support.transient_internet(resource_name, *, timeout=30.0, errnos=())¶: Un administrador de contexto que plantea ResourceDenied cuando varios problemas con la conexión a Internet se manifiestan como excepciones.

test.support.disable_faulthandler()¶: Un administrador de contexto que remplaza sys.stderr con sys.__stderr__.

test.support.gc_collect()¶: Se fuerza la mayor cantidad posible de objetos para ser recolectados. Esto es necesario porque el recolector de basura no garantiza la desasignación oportuna. Esto significa que los métodos __del__ pueden llamarse más tarde de lo esperado y las referencias débiles pueden permanecer vivas por más tiempo de lo esperado.

test.support.disable_gc()¶: Un administrador de contexto que deshabilita el recolector de basura al entrar y lo vuelve a habilitar al salir.

test.support.swap_attr(obj, attr, new_val)¶

Administrador de contexto para intercambiar un atributo con un nuevo objeto.

Uso:

with swap_attr(obj, "attr", 5):
    ...

Esto establecerá obj.attr en 5 durante la duración del bloque with, restaurando el valor anterior al final del bloque. Si attr no existe en obj, se creará y luego se eliminará al final del bloque.

El valor anterior (o None si no existe) se asignará al objetivo de la cláusula «como», si existe.

test.support.swap_item(obj, attr, new_val)¶

Administrador de contexto para intercambiar un elemento con un nuevo objeto.

Uso:

with swap_item(obj, "item", 5):
    ...

Esto establecerá obj ["item"] a 5 durante la duración del bloque with, restaurando el valor anterior al final del bloque. Si item no existe en obj, se creará y luego se eliminará al final del bloque.

El valor anterior (o None si no existe) se asignará al objetivo de la cláusula «como», si existe.

test.support.wait_threads_exit(timeout=60.0)¶: El administrador de contexto debe esperar hasta que salgan todos los hilos creados en la declaración with.

test.support.start_threads(threads, unlock=None)¶: Administrador de contexto para iniciar threads. Intenta unir los hilos al salir.

test.support.calcobjsize(fmt)¶: Retorna struct.calcsize() para nP{fmt}0n o, si gettotalrefcount existe, 2PnP{fmt}0P.

test.support.calcvobjsize(fmt)¶: Retorna struct.calcsize() para nPn{fmt}0n o, si gettotalrefcount existe, 2PnPn{fmt}0P.

test.support.checksizeof(test, o, size)¶: Para el caso de prueba (testcase), se aserciona que el sys.getsizeof para o más el tamaño del encabezado GC es igual a size.

test.support.can_symlink()¶: Retorna True si el sistema operativo admite links simbólicos, de lo contrario False.

test.support.can_xattr()¶: Retorna True si el sistema operativo admite xattr, de lo contrario False.

@test.support.skip_unless_symlink¶: Un decorador para ejecutar pruebas que requieren soporte para enlaces simbólicos.

@test.support.skip_unless_xattr¶: Un decorador para ejecutar pruebas que requieren soporte para xattr.

@test.support.skip_unless_bind_unix_socket¶: Un decorador para ejecutar pruebas que requieren un enlace bind() para sockets Unix.

@test.support.anticipate_failure(condition)¶: Un decorador para marcar condicionalmente las pruebas con unittest.expectedFailure(). Cualquier uso de este decorador debe tener un comentario asociado que identifique el problema relevante del rastreador.

@test.support.run_with_locale(catstr, *locales)¶: Un decorador para ejecutar una función en una configuración regional diferente, restableciéndola correctamente una vez que ha finalizado. catstr es la categoría de configuración regional como una cadena (por ejemplo, "LC_ALL"). Las locales aprobadas se probarán secuencialmente y se utilizará la primera configuración regional válida.

@test.support.run_with_tz(tz)¶: Un decorador para ejecutar una función en una zona horaria específica, restableciéndola correctamente una vez que haya finalizado.

@test.support.requires_freebsd_version(*min_version)¶: Decorador para la versión mínima cuando se ejecuta la prueba en FreeBSD. Si la versión de FreeBSD es inferior al mínimo, aumente unittest.SkipTest.

@test.support.requires_linux_version(*min_version)¶: Decorador para la versión mínima cuando se ejecuta la prueba en Linux. Si la versión de Linux es inferior al mínimo, aumente unittest.SkipTest.

@test.support.requires_mac_version(*min_version)¶: Decorador para la versión mínima cuando se ejecuta la prueba en Mac OS X. Si la versión MAC OS X es menor que la mínima, genere unittest.SkipTest.

@test.support.requires_IEEE_754¶: Decorador para omitir pruebas en plataformas que no son IEEE 754.

@test.support.requires_zlib¶: Decorador para omitir pruebas si zlib no existe.

@test.support.requires_gzip¶: Decorador para omitir pruebas si gzip no existe.

@test.support.requires_bz2¶: Decorador para omitir pruebas si bz2 no existe.

@test.support.requires_lzma¶: Decorador para omitir pruebas si lzma no existe.

@test.support.requires_resource(resource)¶: Decorador para omitir pruebas si resource no está disponible.

@test.support.requires_docstrings¶: Decorador para ejecutar solo la prueba si HAVE_DOCSTRINGS.

@test.support.cpython_only(test)¶: Decorador para pruebas solo aplicable a CPython.

@test.support.impl_detail(msg=None, **guards)¶: Decorador para invocar check_impl_detail() en guards. Si eso retorna False, entonces usa msg como la razón para omitir la prueba.

@test.support.no_tracing(func)¶: Decorador para desactivar temporalmente el seguimiento durante la duración de la prueba.

@test.support.refcount_test(test)¶: Decorador para pruebas que implican conteo de referencias. El decorador no ejecuta la prueba si CPython no la ejecuta. Cualquier función de rastreo no se establece durante la duración de la prueba para evitar conteos de referencia(refcounts) inesperados causados por la función de rastreo.

@test.support.reap_threads(func)¶: Decorador para garantizar que los hilos se limpien incluso si la prueba falla.

@test.support.bigmemtest(size, memuse, dry_run=True)¶

Decorador para pruebas bigmem.

size es un tamaño solicitado para la prueba (en unidades arbitrarias interpretadas por la prueba). memuse es el número de bytes por unidad para la prueba, o una buena estimación de la misma. Por ejemplo, una prueba que necesita dos búfers de byte, de 4 GiB cada uno, podría decorarse con @bigmemtest(size=_4G, memuse=2).

El argumento size normalmente se pasa al método de prueba decorado como un argumento adicional. Si dry_run es True, el valor pasado al método de prueba puede ser menor que el valor solicitado. Si dry_run es False, significa que la prueba no admite ejecuciones ficticias cuando no se especifica -M.

@test.support.bigaddrspacetest(f)¶: Decorador para pruebas que llenan el espacio de direcciones. f es la función para envolver.

test.support.make_bad_fd()¶: Se crea un descriptor de archivo no válido abriendo y cerrando un archivo temporal y retornando su descriptor.

test.support.check_syntax_error(testcase, statement, errtext='', *, lineno=None, offset=None)¶: Prueba los errores de sintaxis en statement intentando compilar statement. testcase es la instancia unittest para la prueba. errtext es la expresión regular que debe coincidir con la representación de cadena de caracteres que es lanza en SyntaxError. Si lineno no es None, se compara con la línea de la excepción. Si offset no es None, se compara con el desplazamiento de la excepción.

test.support.check_syntax_warning(testcase, statement, errtext='', *, lineno=1, offset=None)¶: Prueba la advertencia de sintaxis en statement intentando compilar statement. Pruebe también que SyntaxWarning se emite solo una vez, y que se convertirá en SyntaxError cuando se convierta en error. testcase es la instancia unittest para la prueba. errtext es la expresión regular que debe coincidir con la representación de cadena del emitido SyntaxWarning y lanza SyntaxError . Si lineno no es None, se compara con la línea de advertencia y excepción. Si offset no es None, se compara con el desplazamiento de la excepción.

Nuevo en la versión 3.8.

test.support.open_urlresource(url, *args, **kw)¶: Abre url. Si la apertura falla, se lanza TestFailed.

test.support.import_module(name, deprecated=False, *, required_on())¶

Esta función importa y retorna el módulo nombrado. A diferencia de una importación normal, esta función lanza unittest.SkipTest si el módulo no se puede importar.

Los mensajes de deprecación de módulos y paquetes se suprimen durante esta importación si deprecated es True. Si se requiere un módulo en una plataforma pero es opcional para otros, establezca required_on en un iterable de prefijos de plataforma que se compararán con sys.platform.

Nuevo en la versión 3.1.

test.support.import_fresh_module(name, fresh=(), blocked=(), deprecated=False)¶

Esta función importa y retorna una copia nueva del módulo Python nombrado eliminando el módulo nombrado de sys.modules antes de realizar la importación. Tenga en cuenta que a diferencia de reload(), el módulo original no se ve afectado por esta operación.

fresh es un iterable de nombres de módulos adicionales que también se eliminan del caché sys.modules antes de realizar la importación.

bloqueado es un iterable de nombres de módulos que se reemplazan con None en la memoria caché del módulo durante la importación para garantizar que los intentos de importarlos generen ImportError.

El módulo nombrado y los módulos nombrados en los parámetros fresh y bloqueado se guardan antes de comenzar la importación y luego se vuelven a insertar en sys.modules cuando se completa la importación fresca.

Los mensajes de deprecación de módulos y paquetes se suprimen durante esta importación si deprecated es True.

Esta función lanzará ImportError si el módulo nombrado no puede importarse.

Ejemplo de uso:

# Get copies of the warnings module for testing without affecting the
# version being used by the rest of the test suite. One copy uses the
# C implementation, the other is forced to use the pure Python fallback
# implementation
py_warnings = import_fresh_module('warnings', blocked=['_warnings'])
c_warnings = import_fresh_module('warnings', fresh=['_warnings'])

Nuevo en la versión 3.1.

test.support.modules_setup()¶: Retorna una copia de sys.modules.

test.support.modules_cleanup(oldmodules)¶: Elimina los módulos a excepción de oldmodules y encodings para preservar la memoria caché interna.

test.support.threading_setup()¶: Retorna el recuento del hilo actual y copia de subprocesos colgantes.

test.support.threading_cleanup(*original_values)¶: Se limpia los hilos no especificados en original_values. Diseñado para emitir una advertencia si una prueba deja hilos en ejecución en segundo plano.

test.support.join_thread(thread, timeout=30.0)¶: Se une un thread dentro de timeout. Lanza un AssertionError si el hilo sigue vivo después de unos segundos de timeout.

test.support.reap_children()¶: Se utiliza esto al final de test_main siempre que se inicien subprocesos. Esto ayudará a garantizar que ningún proceso hijo adicional (zombies) se quede para acumular recursos y crear problemas al buscar refleaks.

test.support.get_attribute(obj, name)¶: Obtiene un atributo, lanzando unittest.SkipTest si AttributeError está activado.

test.support.bind_port(sock, host=HOST)¶

Se enlaza el socket a un puerto libre y retorna el número de puerto. Se basa en puertos efímeros para garantizar que estemos utilizando un puerto independiente. Esto es importante ya que muchas pruebas pueden ejecutarse simultáneamente, especialmente en un entorno buildbot. Este método lanza una excepción si sock.family es AF_INET y sock.type es SOCK_STREAM, y el socket tiene SO_REUSEADDR o SO_REUSEPORT establecido en él. Las pruebas nunca deben configurar estas opciones de socket para los sockets TCP/IP. El único caso para configurar estas opciones es probar la multidifusión (multicasting) a través de múltiples sockets UDP.

Además, si la opción de socket SO_EXCLUSIVEADDRUSE está disponible (es decir, en Windows), se establecerá en el socket. Esto evitará que otras personas se vinculen a nuestro host/puerto mientras dure la prueba.

test.support.bind_unix_socket(sock, addr)¶: Enlace un socket Unix, lanzando unittest.SkipTest si PermissionError es lanzado.

test.support.catch_threading_exception()¶

El administrador de contexto captura threading.Thread excepción usando threading.excepthook().

Atributos establecidos cuando se detecta una excepción:

exc_type
exc_value
exc_traceback
thread

Consulte la documentación para threading.excepthook().

Estos atributos se eliminan en la salida del administrador de contexto.

Uso:

with support.catch_threading_exception() as cm:
    # code spawning a thread which raises an exception
    ...

    # check the thread exception, use cm attributes:
    # exc_type, exc_value, exc_traceback, thread
    ...

# exc_type, exc_value, exc_traceback, thread attributes of cm no longer
# exists at this point
# (to avoid reference cycles)

Nuevo en la versión 3.8.

test.support.catch_unraisable_exception()¶

El administrador de contexto detectando excepciones imposibles de evaluar usando sys.unraisablehook().

El almacenamiento del valor de excepción (cm.unraisable.exc_value) crea un ciclo de referencia. El ciclo de referencia se interrumpe explícitamente cuando sale el administrador de contexto.

El almacenamiento del objeto (cm.unraisable.object) puede resucitarlo si se establece en un objeto que se está finalizando. Salir del administrador de contexto borra el objeto almacenado.

Uso:

with support.catch_unraisable_exception() as cm:
    # code creating an "unraisable exception"
    ...

    # check the unraisable exception: use cm.unraisable
    ...

# cm.unraisable attribute no longer exists at this point
# (to break a reference cycle)

Nuevo en la versión 3.8.

test.support.find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM)¶

Retorna un puerto no utilizado que debería ser adecuado para el enlace. Esto se logra creando un socket temporal con la misma familia y tipo que el parámetro sock (el valor predeterminado es AF_INET, SOCK_STREAM) y vinculándolo a la dirección de host especificada (por defecto es 0.0.0.0) con el puerto establecido en 0, provocando un puerto efímero no utilizado del sistema operativo. El socket temporal se cierra y se elimina, y se retorna el puerto efímero.

Este método o bind_port() debe usarse para cualquier prueba en la que un socket del servidor deba estar vinculado a un puerto en particular durante la duración de la prueba. Cuál usar depende de si el código de llamada está creando un socket Python, o si un puerto no utilizado debe proporcionarse en un constructor o pasar a un programa externo (es decir, el argumento -accept al modo s_server de openssl). Siempre es preferible bind_port() sobre find_unused_port() donde sea posible. Se desaconseja el uso de un puerto codificado ya que puede hacer que varias instancias de la prueba sean imposibles de ejecutar simultáneamente, lo cual es un problema para los buildbots.

test.support.load_package_tests(pkg_dir, loader, standard_tests, pattern)¶

La implementación genérica del protocolo unittest load_tests para usar en paquetes de prueba. pkg_dir es el directorio raíz del paquete; loader, standard_tests y pattern son los argumentos esperados por load_tests. En casos simples, el paquete de prueba __init __. Py puede ser el siguiente:

import os
from test.support import load_package_tests

def load_tests(*args):
    return load_package_tests(os.path.dirname(__file__), *args)

test.support.fs_is_case_insensitive(directory)¶: Retorna True si el sistema de archivos para directory no distingue entre mayúsculas y minúsculas.

test.support.detect_api_mismatch(ref_api, other_api, *, ignore=())¶

Retorna el conjunto de atributos, funciones o métodos de ref_api que no se encuentra en other_api *, excepto por una lista definida de elementos que se ignorarán en esta comprobación especificada en *ignore.

De forma predeterminada, omite los atributos privados que comienzan con “_” pero incluye todos los métodos mágicos, es decir, los que comienzan y terminan en “__”.

Nuevo en la versión 3.5.

test.support.patch(test_instance, object_to_patch, attr_name, new_value)¶: Se anula object_to_patch.attr_name con new_value. Se agrega también el procedimiento de limpieza a test_instance para restaurar object_to_patch para attr_name. Attr_name debe ser un atributo válido para object_to_patch.

test.support.run_in_subinterp(code)¶: Ejecuta code en el subinterpretador. Lanza unittest.SkipTest si tracemalloc está habilitado.

test.support.check_free_after_iterating(test, iter, cls, args=())¶: Aserciona que iter se desasigna después de iterar.

test.support.missing_compiler_executable(cmd_names=[])¶: Verifica la existencia de los ejecutables del compilador cuyos nombres figuran en cmd_names o todos los ejecutables del compilador cuando cmd_names está vacío y retorna el primer ejecutable faltante o None cuando no se encuentra ninguno.

test.support.check__all__(test_case, module, name_of_module=None, extra=(), blacklist=())¶

Aserciona que la variable _all__ de module contiene todos los nombres públicos.

Los nombres públicos del módulo (su API) se detectan automáticamente en función de si coinciden con la convención de nombres públicos y se definieron en module.

El argumento name_of_module puede especificar (como una cadena o tupla del mismo) qué módulo(s) se podría definir una API para ser detectada como una API pública. Un caso para esto es cuando module importa parte de su API pública desde otros módulos, posiblemente un backend de C (como csv y su _csv).

El argumento extra puede ser un conjunto de nombres que de otro modo no se detectarían automáticamente como «públicos» («public»), como objetos sin un atributo adecuado __module__. Si se proporciona, se agregará a los detectados automáticamente.

El argumento blacklist puede ser un conjunto de nombres que no deben tratarse como parte de la API pública aunque sus nombres indiquen lo contrario.

Ejemplo de uso:

import bar
import foo
import unittest
from test import support

class MiscTestCase(unittest.TestCase):
    def test__all__(self):
        support.check__all__(self, foo)

class OtherTestCase(unittest.TestCase):
    def test__all__(self):
        extra = {'BAR_CONST', 'FOO_CONST'}
        blacklist = {'baz'}  # Undocumented name.
        # bar imports part of its API from _bar.
        support.check__all__(self, bar, ('bar', '_bar'),
                             extra=extra, blacklist=blacklist)

Nuevo en la versión 3.6.

test.support.adjust_int_max_str_digits(max_digits)¶: This function returns a context manager that will change the global sys.set_int_max_str_digits() setting for the duration of the context to allow execution of test code that needs a different limit on the number of digits when converting between an integer and string.

Nuevo en la versión 3.8.14.

El módulo test.support define las siguientes clases:

class test.support.TransientResource(exc, **kwargs)¶: Las instancias son un administrador de contexto que lanza ResourceDenied si se lanza el tipo de excepción especificado. Cualquier argumento de palabra clave se trata como pares de atributo / valor para compararlo con cualquier excepción lanzada dentro de with. Solo si todos los pares coinciden correctamente con los atributos de la excepción se lanza ResourceDenied.

class test.support.EnvironmentVarGuard¶: Clase utilizada para establecer o deshabilitar temporalmente las variables de entorno. Las instancias se pueden usar como un administrador de contexto y tienen una interfaz de diccionario completa para consultar/modificar el os.environ subyacente. Después de salir del administrador de contexto, todos los cambios en las variables de entorno realizados a través de esta instancia se revertirán.

Distinto en la versión 3.1: Añadido una interfaz de diccionario.

EnvironmentVarGuard.set(envvar, value)¶: Se establece temporalmente la variable de entorno envvar en el valor de value.

EnvironmentVarGuard.unset(envvar)¶: Deshabilita temporalmente la variable de entorno envvar.

class test.support.SuppressCrashReport¶

Un administrador de contexto suele intentar evitar ventanas emergentes de diálogo de bloqueo en las pruebas que se espera que bloqueen un subproceso.

En Windows, deshabilita los cuadros de diálogo de Informe de errores de Windows usando SetErrorMode.

En UNIX, resource.setrlimit() se usa para establecer resource.RLIMIT_CORE del límite flexible a 0 para evitar la creación de archivos coredump.

En ambas plataformas, el valor anterior se restaura mediante __exit__().

class test.support.CleanImport(*module_names)¶

Un administrador de contexto para forzar la importación para que retorne una nueva referencia de módulo. Esto es útil para probar comportamientos a nivel de módulo, como la emisión de una Advertencia de desaprobación en la importación. Ejemplo de uso:

with CleanImport('foo'):
    importlib.import_module('foo')  # New reference.

class test.support.DirsOnSysPath(*paths)¶

Un administrador de contexto para agregar temporalmente directorios a sys.path.

Esto hace una copia de sys.path, agrega cualquier directorio dado como argumento posicional, luego revierte sys.path a la configuración copiada cuando finaliza el contexto.

Tenga en cuenta que all sys.path produce modificaciones en el cuerpo del administrador de contexto, incluida la sustitución del objeto, se revertirán al final del bloque.

class test.support.SaveSignals¶: Clase para guardar y restaurar manejadores (handlers) de señal registrados por el manejador de señal Python.

class test.support.Matcher¶

matches(self, d, **kwargs)¶: Intenta hacer coincidir una sola sentencia con los argumentos proporcionados.

match_value(self, k, dv, v)¶: Intenta hacer coincidir un único valor almacenado (dv) con un valor proporcionado (v).

class test.support.WarningsRecorder¶: La clase utilizada para registrar advertencias para pruebas unitarias. Consulte la documentación de check_warnings() arriba para obtener más detalles.

class test.support.BasicTestRunner¶

run(test)¶: Retorna test y retorna el resultado..

class test.support.TestHandler(logging.handlers.BufferingHandler)¶: Clase para soporte de logging.

class test.support.FakePath(path)¶: Simple path-like object. Se implementa el método __fspath__() que simplemente retorna el argumento path. Si path es una excepción, se lanzará en __ fspath__().

`test.support.script_helper` —Utilidades para las pruebas de ejecución de Python¶

El módulo test.support.script_helper proporciona soporte para las pruebas de ejecución de script de Python.

test.support.script_helper.interpreter_requires_environment()¶

Retorna True` si el sys.executable interpreter requiere variables de entorno para poder ejecutarse.

Esto está diseñado para usarse con @unittest.skipIf() para anotar pruebas que necesitan usar una función assert_python*() para iniciar un modo aislado (-I) o sin entorno proceso de subinterpretador de modo (-E).

Una compilación y prueba normal no se encuentra en esta situación, pero puede suceder cuando se intenta ejecutar el conjunto de pruebas de biblioteca estándar desde un intérprete que no tiene un directorio principal obvio con la lógica de búsqueda de directorio principal actual de Python.

La configuración PYTHONHOME es una forma de hacer que la mayoría del testuite se ejecute en esa situación. PYTHONPATH o PYTHONUSERSITE son otras variables de entorno comunes que pueden afectar si el intérprete puede o no comenzar.

test.support.script_helper.run_python_until_end(*args, **env_vars)¶: Configura el entorno basado en env_vars para ejecutar el intérprete en un subproceso. Los valores pueden incluir __isolated, __cleanenv, __cwd y TERM.

test.support.script_helper.assert_python_ok(*args, **env_vars)¶

Aserción de que ejecutar el intérprete con arg y variables de entorno opcionales env_vars tiene éxito (rc == 0) y retorna una tupla (código de retorno, stdout, stderr).

Si se establece la palabra clave __cleanenv, env_vars se usa como un entorno nuevo.

Python se inicia en modo aislado (opción de línea de comando -I), excepto si la palabra clave __isolated se establece en False.

test.support.script_helper.assert_python_failure(*args, **env_vars)¶

Aserciona que la ejecución del intérprete con args y variables de entorno opcionales env_vars falla (rc! = 0) y retorna una tupla (return code, stdout, stderr).

Consulte assert_python_ok() para más opciones.

test.support.script_helper.spawn_python(*args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, **kw)¶

Ejecuta un subproceso de Python con los argumentos dados.

kw es un argumento adicional de palabras clave para pasar a subprocess.Popen(). Retorna un objeto a subprocess.Popen.

test.support.script_helper.kill_python(p)¶: Ejecuta el proceso dado subprocess.Popen hasta que finalice y retorne stdout.

test.support.script_helper.make_script(script_dir, script_basename, source, omit_suffix=False)¶: Crea un script que contiene source en la ruta script_dir y script_basename. Si omit_suffix es False, agregue .py al nombre. Retorna la ruta completa del script.

test.support.script_helper.make_zip_script(zip_dir, zip_basename, script_name, name_in_zip=None)¶: Crea un archivo zip en zip_dir y zip_basename con la extensión zip que contiene los archivos en script_name. name_in_zip es el nombre del archivo. Retorna una tupla que contiene (ruta completa, ruta completa del nombre del archivo).

test.support.script_helper.make_pkg(pkg_dir, init_source='')¶: Crea un directorio llamado pkg_dir que contiene un archivo __init__ con init_source como su contenido.

test.support.script_helper.make_zip_pkg(zip_dir, zip_basename, pkg_name, script_basename, source, depth=1, compiled=False)¶: Crea un directorio de paquete zip con una ruta de zip_dir y zip_basename que contiene un archivo __init__ vacío y un archivo script_basename que contiene el source. Si compilado es True, ambos archivos fuente se compilarán y se agregarán al paquete zip. Retorna una tupla de la ruta zip completa y el nombre de archivo para el archivo zip.

`test` — Paquete de pruebas de regresión para Python¶

Escritura de pruebas unitarias para el paquete `test`¶

Ejecución de pruebas utilizando la interfaz de línea de comandos¶

`test.support` — Utilidades para el conjunto de pruebas de Python¶

`test.support.script_helper` —Utilidades para las pruebas de ejecución de Python¶

Tabla de contenido

Tema anterior

Próximo tema

Esta página

test — Paquete de pruebas de regresión para Python¶

Escritura de pruebas unitarias para el paquete test¶

Ejecución de pruebas utilizando la interfaz de línea de comandos¶

test.support — Utilidades para el conjunto de pruebas de Python¶

test.support.script_helper —Utilidades para las pruebas de ejecución de Python¶

`test` — Paquete de pruebas de regresión para Python¶

Escritura de pruebas unitarias para el paquete `test`¶

`test.support` — Utilidades para el conjunto de pruebas de Python¶

`test.support.script_helper` —Utilidades para las pruebas de ejecución de Python¶