# `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 `unittest`y 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.``LOOPBACK_TIMEOUT`

  Tiempo de espera en segundos para las pruebas que utilizan un servidor de red que escucha en la interfaz local de loopback de la red como `127.0.0.1`.

  El tiempo de espera es lo suficientemente largo para evitar el fracaso de la prueba: tiene en cuenta que el cliente y el servidor pueden ejecutarse en diferentes hilos o incluso en diferentes procesos.

  El tiempo de espera debe ser lo suficientemente largo para los métodos `connect()`, `recv()` y `send()` de `socket.socket`.

  Su valor por defecto es de 5 segundos.

  Ver también `INTERNET_TIMEOUT`.

`test.support.``INTERNET_TIMEOUT`

  Tiempo de espera en segundos para las solicitudes de red que van a Internet.

  El tiempo de espera es lo suficientemente corto como para evitar que una prueba espere demasiado tiempo si la solicitud de Internet se bloquea por cualquier motivo.

  Normalmente, un tiempo de espera utilizando `INTERNET_TIMEOUT` no debería marcar una prueba como fallida, sino que debería omitir la prueba: ver `transient_internet()`.

  Su valor por defecto es de 1 minuto.

  Ver también `LOOPBACK_TIMEOUT`.

`test.support.``SHORT_TIMEOUT`

  Tiempo de espera en segundos para marcar una prueba como fallida si la prueba tarda «demasiado».

  El valor del tiempo de espera depende de la opción de línea de comandos regrtest `--timeout`.

  Si una prueba que utiliza `SHORT_TIMEOUT` empieza a fallar aleatoriamente en buildbots lentos, utilice en su lugar `LONG_TIMEOUT`.

  Su valor por defecto es de 30 segundos.

`test.support.``LONG_TIMEOUT`

  Tiempo de espera en segundos para detectar cuando se cuelga una prueba.

  Es lo suficientemente largo como para reducir el riesgo de fracaso de la prueba en los buildbots de Python más lentos. No debe utilizarse para marcar una prueba como fallida si la prueba tarda «demasiado». El valor del tiempo de espera depende de la opción de línea de comandos regrtest `--timeout`.

  Su valor por defecto es de 5 minutos.

  Ver también `LOOPBACK_TIMEOUT`, `INTERNET_TIMEOUT` y `SHORT_TIMEOUT`.

`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.``NEVER_EQ`

  Objeto que no es igual a nada (incluso a `ALWAYS_EQ`). 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)

  Call `os.unlink()` on filename. On Windows platforms, this is wrapped with a wait loop that checks for the existence of the file.

`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.``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.``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.``print_warning`(msg)

  Imprime una advertencia en `sys.__stderr__`. Formatea el mensaje como: `f "Warning -- {msg}"`. Si msg se compone de varias líneas, añade el prefijo `"Warning --"` a cada línea.

  Nuevo en la versión 3.9.

`test.support.``wait_process`(pid, *, exitcode, timeout=None)

  Espere hasta que el proceso pid termine y comprobará que el código de salida del proceso es exitcode.

  Lanza un `AssertionError` si el código de salida del proceso no es igual a exitcode.

  Si el proceso se ejecuta durante más tiempo que timeout en segundos (`SHORT_TIMEOUT` por defecto), mata el proceso y lanza un `AssertionError`. La función de tiempo de espera no está disponible en Windows.

  Nuevo en la versión 3.9.

`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.``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)

  Decorator for the minimum version when running test on macOS. If the macOS version is less than the minimum, raise `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.``catch_threading_exception`()

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

  Attributes set when an exception is caught:

  - `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.``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.9.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.``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.socket_helper` — Utilidades para pruebas de socket

El módulo `test.support.socket_helper` proporciona soporte para las pruebas de socket.

Nuevo en la versión 3.9.

`test.support.socket_helper.``IPV6_ENABLED`

  Se establece como `True` si IPv6 está habilitado en este host, `False` en caso contrario.

`test.support.socket_helper.``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.socket_helper.``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.socket_helper.``bind_unix_socket`(sock, addr)

  Enlace un socket Unix, lanzando `unittest.SkipTest` si `PermissionError` es lanzado.

`@``test.support.socket_helper.``skip_unless_bind_unix_socket`

  Un decorador para ejecutar pruebas que requieren un enlace(`bind()`) funcional para sockets en sistemas Unix.

`test.support.socket_helper.``transient_internet`(resource_name, *, timeout=30.0, errnos=())

  Un gestor de contexto que lanza `ResourceDenied` cuando varios problemas con la conexión a Internet se manifiestan como excepciones.

# `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`.

  Distinto en la versión 3.9: La función ya no elimina los espacios en blanco de stderr.

`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`.

  Distinto en la versión 3.9: La función ya no elimina los espacios en blanco de stderr.

`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.

  Distinto en la versión 3.9: La función ya no elimina los espacios en blanco de stderr.

`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.support.bytecode_helper` — Herramientas de apoyo para comprobar la correcta generación de bytecode

El módulo `test.support.bytecode_helper` proporciona soporte para probar e inspeccionar la generación de código de bytes.

Nuevo en la versión 3.9.

El módulo define la siguiente clase:

class `test.support.bytecode_helper.``BytecodeTestCase`(unittest.TestCase)

  Esta clase tiene métodos de aserción personalizados para inspeccionar el código de bytes.

`BytecodeTestCase.``get_disassembly_as_string`(co)

  Retorna el desensamblaje de co como cadena.

`BytecodeTestCase.``assertInBytecode`(x, opname, argval=_UNSPECIFIED)

  Retorna instr si se encuentra opname, de lo contrario lanza `AssertionError`.

`BytecodeTestCase.``assertNotInBytecode`(x, opname, argval=_UNSPECIFIED)

  Lanza `AssertionError` si se encuentra opname.