# `unittest` — Infraestructura de tests unitarios

Código fuente: Lib/unittest/__init__.py

(Si ya estás familiarizado con los conceptos básicos de realización de tests, puedes saltar a la lista de métodos de aserción.)

La infraestructura de tests unitarios `unittest` se inspiró en primera instancia en JUnit y ofrece aspectos similares a las principales estructuras de tests unitarios más importantes de otros lenguajes. Da soporte a automatización de tests, inicialización compartida, código de cierre de los tests, agregación de los tests en colecciones e independencia de los tests de la infraestructura que los reporta.

Para conseguir esto, `unittest` da soporte a ciertos conceptos importantes de una forma orientada a objetos:

configuración de prueba (fixture)

  Un test fixture representa los preparativos para realizar una o más pruebas y las acciones de limpieza asociadas. Esto puede incluir, por ejemplo, la creación de bases de datos temporales, directorios o el arranque de procesos del servidor.

caso de prueba

  Un test case es la unidad mínima de prueba. Verifica la respuesta específica a un juego particular de entradas. `unittest` proporciona una clase base, `TestCase`, que se puede utilizar para crear nuevos casos de uso.

conjunto de pruebas

  Un test suite es una colección de casos de prueba, juegos de prueba o ambos. Se usa para agrupar pruebas que se han de ejecutar juntas.

ejecutor de pruebas

  Un test runner es un componente que dirige la ejecución de las pruebas y proporciona un resultado. El ejecutor puede disponer de una interfaz gráfica, de texto o devolver un valor especial que indique el resultado de la ejecución de las pruebas.

Ver también

Módulo `doctest`

  Otro módulo de soporte a pruebas con una solución muy diferente.

Simple Smalltalk Testing: With Patterns

  El documento original de Kent Beck sobre infraestructuras de prueba mediante el patrón que utiliza `unittest`.

pytest

  Una infraestructura de pruebas unitarias de otro proveedor con una sintaxis más ligera de escritura de pruebas, por ejemplo: `assert func(10) == 42`.

The Python Testing Tools Taxonomy

  Una lista extensa de herramientas de prueba para Python incluyendo infraestructuras de pruebas funcionales y librerías de objetos sucedáneos.

Testing in Python Mailing List

  Grupo especializado en debate sobre las pruebas y las herramientas de prueba de Python.

El script `Tools/unittestgui/unittestgui.py` de la distribución de fuentes de Python es una herramienta gráfica para el descubrimiento y ejecución de pruebas. Está orientado sobre todo a principiantes en el tema de pruebas. Para entornos de producción se recomienda que las pruebas sean dirigidas por un sistema de integración continua como Buildbot, Jenkins o Hudson.

## Ejemplo sencillo

El módulo `unittest` proporciona un conjunto de herramientas para construir y ejecutar pruebas. Esta sección demuestra que un pequeño subconjunto de las herramientas es suficiente para satisfacer las necesidades de la mayoría.

He aquí un breve script para probar estros tres métodos de cadena:

    import unittest

    class TestStringMethods(unittest.TestCase):

        def test_upper(self):
            self.assertEqual('foo'.upper(), 'FOO')

        def test_isupper(self):
            self.assertTrue('FOO'.isupper())
            self.assertFalse('Foo'.isupper())

        def test_split(self):
            s = 'hello world'
            self.assertEqual(s.split(), ['hello', 'world'])
            # check that s.split fails when the separator is not a string
            with self.assertRaises(TypeError):
                s.split(2)

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

Para crear un caso de prueba se genera una subclase de `unittest.TestCase`. Las tres pruebas se definen con métodos cuyos nombres comienzan por las letras `test`. Esta convención sobre nombres indica al ejecutor de pruebas qué métodos representan pruebas.

El quid de cada test es la llamada a `assertEqual()` para verificar un resultado esperado; `assertTrue()` o `assertFalse()` para verificar una condición; o `assertRaises()` para asegurar que se lanza una excepción específica. Se utilizan estos métodos en lugar de la sentencia `assert` para que el ejecutor de pruebas pueda acumular todos los resultados de la prueba de cara a realizar un informe.

Los métodos `setUp()` y `tearDown()` permiten definir instrucciones que han de ser ejecutadas antes y después, respectivamente, de cada método de prueba. Se describen con mas detalle en la sección Organización del código de pruebas.

El bloque final muestra un modo sencillo de ejecutar las pruebas. `unittest.main()` proporciona una interfaz de línea de órdenes para el script de prueba. Cuando se ejecuta desde la línea de órdenes, el script anterior produce una salida como:

    ...
    ----------------------------------------------------------------------
    Ran 3 tests in 0.000s

    OK

Si se le pasa una opción `-v` al script de prueba, se establecerá un nivel mayor de detalle del proceso de `unittest.main()` y se obtendrá la siguiente salida:

    test_isupper (__main__.TestStringMethods) ... ok
    test_split (__main__.TestStringMethods) ... ok
    test_upper (__main__.TestStringMethods) ... ok

    ----------------------------------------------------------------------
    Ran 3 tests in 0.001s

    OK

Los ejemplos anteriores muestra las características más usuales de `unittest`, que son suficientes para solventar las necesidades cotidianas de pruebas. El resto de la documentación explora el juego completo de características, que abundan en los mismos principios.

## Interfaz de línea de comandos

Se puede usar el módulo unittest desde la línea de órdenes para ejecutar pruebas de módulos, clases o hasta métodos de prueba individuales:

    python -m unittest test_module1 test_module2
    python -m unittest test_module.TestClass
    python -m unittest test_module.TestClass.test_method

Se puede pasar una lista con cualquier combinación de nombres de módulo, así como clases o métodos completamente cualificados.

Se puede especificar los módulos de prueba por ruta de fichero también:

    python -m unittest tests/test_something.py

Esto permite usar el completado automático de nombre de fichero de la shell para especificar el módulo de pruebas. El fichero especificado aún debe ser susceptible de importarse como módulo. La ruta se convierte en nombre de módulo eliminando “.py” y convirtiendo el separador de directorios por “.”. Si se desea ejecutar un fichero de prueba que no se puede importar como módulo, se ha de ejecutar el fichero directamente.

Se pueden ejecutar las pruebas con más nivel de detalle (mayor verbosidad) pasando el parámetro -v:

    python -m unittest -v test_module

Cuando se ejecuta sin argumentos, se inicia Descubrimiento de pruebas:

    python -m unittest

Para obtener una lista de todas las opciones de línea de órdenes:

    python -m unittest -h

Distinto en la versión 3.2: En versiones anteriores sólo era posible ejecutar métodos de prueba individuales, pero no módulos ni clases.

### Opciones de la línea de órdenes

unittest da soporte a las siguientes opciones de línea de órdenes:

`-b````,` `--buffer```

  Los flujos de datos de salida estándar y error estándar se acumulan en un búfer durante la ejecución de pruebas. La salida de las pruebas correctas se descarta. La salida de las pruebas que fallan o devuelven un error se añade a los mensajes de fallo.

`-c````,` `--catch```

  La pulsación de `Control-C` durante la ejecución de pruebas espera a que termine la prueba en curso y da un informe de los resultados hasta ese momento. Una segunda pulsación de `Control-C` lanza la excepción `KeyboardInterrupt` usual.

  Consultar en Gestión de señales las funciones que proporcionan esta funcionalidad.

`-f````,` `--failfast```

  Finaliza la ejecución tras el primer error o fallo.

`-k```

  Only run test methods and classes that match the pattern or substring. This option may be used multiple times, in which case all test cases that match any of the given patterns are included.

  Los patrones que contengan un comodín (`*`) se comprueban contra el nombre de la prueba usando `fnmatch.fnmatchcase()`; si no lo contienen, se usa una comprobación de contenido simple sensible a mayúsculas.

  Los patrones se comprueban contra el nombre del método completamente cualificado como lo importa el cargador de pruebas.

  Por ejemplo, `-k foo` coincide con `foo_tests.SomeTest.test_something` y con `bar_tests.SomeTest.test_foo`, pero no con `bar_tests.FooTest.test_something`.

`--locals```

  Mostrar las variables locales en las trazas.

Nuevo en la versión 3.2: Se añadieron las opciones de línea de órdenes `-b`, `-c` y `-f`.

Nuevo en la versión 3.5: La opción de línea de órdenes `--locals`.

Nuevo en la versión 3.7: La opción de línea de órdenes `-k`.

La línea de órdenes también se puede usar para descubrimiento de pruebas, para ejecutar todas las pruebas de un proyecto o un subconjunto de éstas.

## Descubrimiento de pruebas

Nuevo en la versión 3.2.

Unittest da soporte al descubrimiento de pruebas simples. Para ser compatible con el descubrimiento de pruebas, todos los ficheros de prueba deben ser módulos o paquetes (incluyendo paquetes nominales) importables desde el directorio superior del proyecto (por lo que sus nombres han de ser identificadores válidos).

El descubrimiento de pruebas está implementado en `TestLoader.discover()`, pero también se puede usar desde la línea de órdenes. La línea de órdenes básica es:

    cd project_directory
    python -m unittest discover

Nota

Como atajo, `python -m unittest` es el equivalente de `python -m unittest discover`. Si se desea pasar argumentos al descubrimiento de pruebas, hay que pasar la sub-orden `discover` explícitamente.

La sub-orden `discover` cuenta con las siguientes opciones:

`-v````,` `--verbose```

  Salida verbosa

`-s````,` `--start-directory` `directory`

  Directorio de inicio para el descubrimiento (`.` si se omite)

`-p````,` `--pattern` `pattern`

  Patrón para la búsqueda de ficheros de prueba (`test*.py` si se omite)

`-t````,` `--top-level-directory` `directory`

  Directorio superior del proyecto (el directorio inicial si se omite)

Las opciones `-s`, `-p`, y `-t` se pueden pasar por posición en el orden mostrado. Las siguientes líneas de órdenes son equivalentes:

    python -m unittest discover -s project_directory -p "*_test.py"
    python -m unittest discover project_directory "*_test.py"

Además de pasar una ruta, es posible pasar el nombre de un paquete, por ejemplo `myproject.subpackage.test`, como directorio de inicio. El nombre de paquete proporcionado será importado y su ubicación en el sistema de archivos será utilizada como directorio de inicio.

Prudencia

El descubrimiento de pruebas carga las pruebas importándolas. Una vez que el descubrimiento ha encontrado todos los ficheros de prueba a partir del directorio inicial, especificado, convierte las rutas en nombres de paquetes a importar. Por ejemplo, `foo/bar/baz.py` será importado como `foo.bar.baz`.

Si hay un paquete instalado globalmente y se intenta hacer un descubrimiento sobre una copia diferente a la instalada del paquete, podría ocurrir que se importe la versión incorrecta. Si ocurre esto, el descubrimiento lanza una advertencia y abandona.

Si se proporciona el directorio de inicio como nombre de paquete en lugar de ruta a un directorio, el descubrimiento asume que la ubicación importada es la deseada, así que no se da la advertencia descrita.

Los módulos y paquetes de prueba pueden personalizar la carta y descubrimiento de pruebas mediante el protocolo load_tests.

Distinto en la versión 3.4: Test discovery supports namespace packages for the start directory. Note that you need to specify the top level directory too (e.g. `python -m unittest discover -s root/namespace -t root`).

## Organización del código de pruebas

Los bloques de construcción básicos de las pruebas unitarias son los test cases, escenarios simples que se han de configurar y cuya corrección hay que comprobar. En `unittest`, los casos de prueba están representados por instancias de `unittest.TestCase`. Para crear nuevos casos de prueba, hay que escribir subclases de `TestCase` o usar `FunctionTestCase`.

El código de pruebas de una instancia de `TestCase` debería ser completamente autónomo, de tal modo que se pueda ejecutar aisladamente o en una combinación arbitraria con otras clases de prueba.

La subclase más simple de `TestCase` se limita a implementar un método test (o un método que empiece por `test`) para realizar código de prueba específico:

    import unittest

    class DefaultWidgetSizeTestCase(unittest.TestCase):
        def test_default_widget_size(self):
            widget = Widget('The widget')
            self.assertEqual(widget.size(), (50, 50))

Adviértase que para probar algo, usamos uno de los métodos `assert*()` proporcionados por la clase base `TestCase`. Si la prueba no tiene éxito, se lanzará una excepción con un mensaje explicativo y `unittest` identificará el caso como failure. Cualquier otra excepción se considerará un errors.

Las pruebas pueden ser muchas y su preparación puede ser repetitiva. Por suerte, se puede «sacar factor común» a la preparación implementando un método `setUp()`, al que la infraestructura de prueba llamará para cada prueba que se ejecute:

    import unittest

    class WidgetTestCase(unittest.TestCase):
        def setUp(self):
            self.widget = Widget('The widget')

        def test_default_widget_size(self):
            self.assertEqual(self.widget.size(), (50,50),
                             'incorrect default size')

        def test_widget_resize(self):
            self.widget.resize(100,150)
            self.assertEqual(self.widget.size(), (100,150),
                             'wrong size after resize')

Nota

El orden en que se ejecutan las diversas pruebas se determina por orden alfabético de los nombres de métodos de prueba.

Si el método `setUp()` lanza una excepción mientras se ejecuta la prueba, la infraestructura considerará que la prueba ha sufrido un error y no se ejecutará el método de prueba propiamente dicho.

Análogamente, se puede proporcionar un método `tearDown()` que haga limpieza después de que se ejecute el método de prueba:

    import unittest

    class WidgetTestCase(unittest.TestCase):
        def setUp(self):
            self.widget = Widget('The widget')

        def tearDown(self):
            self.widget.dispose()

Si `setUp()` se ejecuta sin errores, `tearDown()` se ejecutará tanto si el método de prueba tuvo éxito como si no.

Un entorno de trabajo así para el código de pruebas se llama test fixture . Se crea una nueva instancia de TestCase como juego de datos de prueba que se utiliza para cada método de prueba. De este modo, `setUp()`, `tearDown()` y `__init__()` se llamarán una vez por prueba.

Se recomienda usar implementaciones de TestCase para agrupar las pruebas de acuerdo con las características probadas. `unittest` proporciona una mecanismo para esto: el test suite, representado por la clase `TestSuite` de `unittest`. En la mayor parte de los casos, llamar a `unittest.main()` hará lo correcto y recolectará todos los casos de prueba del módulo para su ejecución.

Sin embargo, si se desea personalizar la construcción del paquete de pruebas, se puede hacer:

    def suite():
        suite = unittest.TestSuite()
        suite.addTest(WidgetTestCase('test_default_widget_size'))
        suite.addTest(WidgetTestCase('test_widget_resize'))
        return suite

    if __name__ == '__main__':
        runner = unittest.TextTestRunner()
        runner.run(suite())

Se puede poner las definiciones de los casos de prueba y de los paquetes de prueba en los mismos módulos que el código que prueban.(tal como `widget.py`), pero sacarlos a un módulo aparte como `test_widget.py` tiene diversas ventajas:

- El módulo de pruebas se puede ejecutar aisladamente desde la línea de órdenes.

- El código de pruebas se puede separar con más facilidad del código de producción.

- Disminuye la tentación de cambiar el código de prueba para ajustarse al código bajo prueba.

- El código de pruebas debería modificarse con mucha menor frecuencia que el código bajo prueba.

- Es más sencillo refactorizar el código bajo prueba.

- El código para probar módulos escritos en C ha de estar en módulos aparte, así que ¿por qué no mantener la consistencia?

- Si cambia la estrategia de prueba, no hay razón para cambiar el código fuente principal.

## Reutilización de código de prueba anterior

Habrá personas que tengan código de prueba previo que deseen ejecutar desde `unittest`, sin conversión previa de cada antigua función de prueba a una subclase de `TestCase`.

Por esto, `unittest` proporciona una clase `FunctionTestCase`. Se puede utilizar esta subclase de `TestCase` para envolver una función de prueba existente. Se pueden proporcionar también funciones de preparación y desmontaje.

Dada la siguiente función de prueba:

    def testSomething():
        something = makeSomething()
        assert something.name is not None
        # ...

se puede crear una instancia de caso de prueba de la siguiente manera, con métodos opcionales de preparación y desmontaje:

    testcase = unittest.FunctionTestCase(testSomething,
                                         setUp=makeSomethingDB,
                                         tearDown=deleteSomethingDB)

Nota

Aunque se puede usar `FunctionTestCase` para convertir rápidamente unas pruebas existentes a un sistema basado en `unittest`, no es una vía recomendada. Tomarse el tiempo de construir subclases bien construidas de `TestCase` hará las futuras refactorizaciones de pruebas futura considerablemente más fácil.

En algunos casos, los tests existentes pueden haber sido escritos usando el módulo `doctest`. En ese caso, `doctest` tiene una clase `DocTestSuite` que puede construir automáticamente instancias de `unittest.TestSuite` partiendo de los test basados en `doctest`.

## Omitir tests y fallos esperados

Nuevo en la versión 3.1.

Unittest soporta omitir métodos individuales de tests e incluso clases completas de tests. Además, soporta marcar un test como un «fallo esperado», un test que está roto y va a fallar, pero no debería ser contado como fallo en `TestResult`.

Omitir un test es solo cuestión de emplear el decorator `skip()` o una de sus variantes condicionales, llamando a `TestCase.skipTest()` dentro de `setUp()` o en un método de test, o lanzando `SkipTest` directamente.

La omisión más básica tiene la siguiente forma:

    class MyTestCase(unittest.TestCase):

        @unittest.skip("demonstrating skipping")
        def test_nothing(self):
            self.fail("shouldn't happen")

        @unittest.skipIf(mylib.__version__ < (1, 3),
                         "not supported in this library version")
        def test_format(self):
            # Tests that work for only a certain version of the library.
            pass

        @unittest.skipUnless(sys.platform.startswith("win"), "requires Windows")
        def test_windows_support(self):
            # windows specific testing code
            pass

        def test_maybe_skipped(self):
            if not external_resource_available():
                self.skipTest("external resource not available")
            # test code that depends on the external resource
            pass

Esta es la salida de ejecutar el ejemplo superior en modo verboso:

    test_format (__main__.MyTestCase) ... skipped 'not supported in this library version'
    test_nothing (__main__.MyTestCase) ... skipped 'demonstrating skipping'
    test_maybe_skipped (__main__.MyTestCase) ... skipped 'external resource not available'
    test_windows_support (__main__.MyTestCase) ... skipped 'requires Windows'

    ----------------------------------------------------------------------
    Ran 4 tests in 0.005s

    OK (skipped=4)

Las clases pueden ser omitidas igual que los métodos:

    @unittest.skip("showing class skipping")
    class MySkippedTestCase(unittest.TestCase):
        def test_not_run(self):
            pass

`TestCase.setUp()` puede omitir también el test. Esto es útil cuando un recurso que necesita ser puesto a punto no está disponible.

Los fallos esperados emplean el decorador `expectedFailure()`.

    class ExpectedFailureTestCase(unittest.TestCase):
        @unittest.expectedFailure
        def test_fail(self):
            self.assertEqual(1, 0, "broken")

Es fácil lanzar tus propios decoradores que omitan haciendo un decorador que llame a `skip()` en el test cuando quiere ser omitido. Este decorador omite el test a menos que el objeto pasado tenga un cierto atributo:

    def skipUnlessHasattr(obj, attr):
        if hasattr(obj, attr):
            return lambda func: func
        return unittest.skip("{!r} doesn't have {!r}".format(obj, attr))

Los siguientes decoradores y la excepción implementan la omisión de tests y los fallos esperados:

`@``unittest.``skip`(reason)

  Omitir incondicionalmente el test decorado. reason debe describir porqué el test está siendo omitido.

`@``unittest.``skipIf`(condition, reason)

  Omitir el test decorado si condition es verdadero.

`@``unittest.``skipUnless`(condition, reason)

  Omitir el test decorado a menos que condition sea verdadero.

`@``unittest.``expectedFailure`

  Mark the test as an expected failure or error. If the test fails or errors in the test function itself (rather than in one of the test fixture methods) then it will be considered a success. If the test passes, it will be considered a failure.

exception `unittest.``SkipTest`(reason)

  Esta excepción es lanzada para omitir un test.

  Normalmente puedes usar directamente `TestCase.skipTest()` o uno de los decoradores de omisión en vez de lanzar esta excepción.

Los tests omitidos no ejecutarán `setUp()` o `tearDown()`. Las clases omitidas no ejecutarán `setUpClass()` o `tearDownClass()`. Los módulos omitidos no ejecutarán `setUpModule()` o `tearDownModule()`.

## Distinguiendo iteraciones de tests empleando subtests

Nuevo en la versión 3.4.

Cuando hay diferencias muy pequeñas entre tus tests, por ejemplo algunos parámetros, unittest te permite distinguirlos dentro del cuerpo de un método de test empleando el administrador de contexto `subTest()` .

Por ejemplo, el siguiente test:

    class NumbersTest(unittest.TestCase):

        def test_even(self):
            """
            Test that numbers between 0 and 5 are all even.
            """
            for i in range(0, 6):
                with self.subTest(i=i):
                    self.assertEqual(i % 2, 0)

producirá la siguiente salida:

    ======================================================================
    FAIL: test_even (__main__.NumbersTest) (i=1)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "subtests.py", line 32, in test_even
        self.assertEqual(i % 2, 0)
    AssertionError: 1 != 0

    ======================================================================
    FAIL: test_even (__main__.NumbersTest) (i=3)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "subtests.py", line 32, in test_even
        self.assertEqual(i % 2, 0)
    AssertionError: 1 != 0

    ======================================================================
    FAIL: test_even (__main__.NumbersTest) (i=5)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "subtests.py", line 32, in test_even
        self.assertEqual(i % 2, 0)
    AssertionError: 1 != 0

Sin usar un subtest, la ejecución se pararía después del primer fallo, y el error sería más difícil de diagnosticar porque el valor de `i` no se mostraría:

    ======================================================================
    FAIL: test_even (__main__.NumbersTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "subtests.py", line 32, in test_even
        self.assertEqual(i % 2, 0)
    AssertionError: 1 != 0

## Clases y funciones

Esta sección describe en detalle la API de `unittest`.

### Casos de test

class `unittest.``TestCase`(methodName='runTest')

  Las instancias de la clase `TestCase` representan las unidades lógicas de test en el universo de `unittest`. Esta clase está pensada para ser utilizada como clase base, con los test específicos siendo implementados por subclases concretas. Esta clase implementa la interfaz que necesita el ejecutor de tests para permitirle llevar a cabo los tests, y métodos que el código de test puede utilizar para chequear y reportar distintos tipos de fallo.

  Cada instancia de `TestCase` ejecutará un solo método base: el método llamado methodName. En la mayoría de usos de `TestCase`, no tendrás que cambiar el methodName ni reimplementar el método por defecto `runTest()`.

  Distinto en la versión 3.2: `TestCase` puede instancias con éxito sin dar un methodName. Esto permite experimentar de manera sencilla con `TestCase` en el intérprete interactivo.

  Las instancias de `TestCase` proveen tres grupos de métodos: un grupo empleado para ejecutar el test, otro usado para que la implementación del test chequee condiciones y reporte fallos, y algunos métodos de indagación que permiten recopilar información sobre el test en si mismo.

  Los métodos en el primer grupo (ejecutando el test) son:

  `setUp`()

    Método llamado para preparar el banco de test. Es invocado inmediatamente antes de llamar al método de test; cualquier excepción lanzada por este método que no sea `AssertionError` o `SkipTest` será considerada un error en vez de un fallo del test. La implementación por defecto no hace nada.

  `tearDown`()

    Método llamado inmediatamente después de que se haya llamado el método de prueba y se haya registrado el resultado. Se llama así aunque el método de ensayo haya planteado una excepción, por lo que la aplicación en las subclases puede tener que ser especialmente cuidadosa en cuanto a la comprobación del estado interno. Cualquier excepción, que no sea `AssertionError` o `SkipTest`, planteada por este método se considerará un error adicional en lugar de un fallo de la prueba (aumentando así el número total de errores reportados). Este método sólo se llamará si `setUp()` tiene éxito, independientemente del resultado del método de prueba. La implementación por defecto no hace nada.

  `setUpClass`()

    Un método de clase llamado antes de que los tests en una clase individual sean ejecutados. `setUpClass` es llamado con la clase como el único argumento y debe ser decorada como `classmethod()`:

        @classmethod
        def setUpClass(cls):
            ...

    Vea Class and Module Fixtures para más detalles.

    Nuevo en la versión 3.2.

  `tearDownClass`()

    Un método de clase llamado después de que se hayan realizado tests en una clase individual. `tearDownClass` se llama con la clase como único argumento y debe ser decorado como un `classmethod()`:

        @classmethod
        def tearDownClass(cls):
            ...

    Vea Class and Module Fixtures para más detalles.

    Nuevo en la versión 3.2.

  `run`(result=None)

    Ejecutar la prueba, recogiendo el resultado en el objeto `TestResult` pasado como result. Si se omite result o `None`, se crea un objeto resultado temporal (llamando al método `defaultTestResult()`) y se emplea ese. El objeto resultante se devuelve al invocador de `run()`.

    El mismo efecto puede conseguirse simplemente llamando a la instancia `TestCase`.

    Distinto en la versión 3.3: Las versiones previas de `run` no retornaban el resultado. Tampoco lo hacía la llamada a una instancia.

  `skipTest`(reason)

    Llamar a esto durante un método de prueba o `setUp()` se salta el test actual. Ver Omitir tests y fallos esperados para más información.

    Nuevo en la versión 3.1.

  `subTest`(msg=None, **params)

    Retorna un gestor de contexto que ejecuta el bloque de código adjunto como un subtest. msg y params son valores opcionales y arbitrarios que se muestran cuando falla un subtest, permitiéndole identificarlos claramente.

    Un caso de test puede contener cualquier número de declaraciones de subtest, y pueden anidarse arbitrariamente.

    Ver Distinguiendo iteraciones de tests empleando subtests para más información.

    Nuevo en la versión 3.4.

  `debug`()

    Realice el test sin recoger el resultado. Esto permite que las excepciones planteadas por el test se propaguen al invocado, y puede utilizarse para apoyar la ejecución de tests bajo un depurador.

  La clase `TestCase` proporciona varios métodos de afirmación para comprobar y reportar fallos. En la siguiente tabla se enumeran los métodos más utilizados (consulte las tablas siguientes para ver más métodos de afirmación):

  Método | Comprueba que | Nuevo en
  --- | --- | ---
  `assertEqual(a, b)` | `a == b` |
  `assertNotEqual(a, b)` | `a != b` |
  `assertTrue(x)` | `bool(x) is True` |
  `assertFalse(x)` | `bool(x) is False` |
  `assertIs(a, b)` | `a is b` | 3.1
  `assertIsNot(a, b)` | `a is not b` | 3.1
  `assertIsNone(x)` | `x is None` | 3.1
  `assertIsNotNone(x)` | `x is not None` | 3.1
  `assertIn(a, b)` | `a in b` | 3.1
  `assertNotIn(a, b)` | `a not in b` | 3.1
  `assertIsInstance(a, b)` | `isinstance(a, b)` | 3.2
  `assertNotIsInstance(a, b)` | `not isinstance(a, b)` | 3.2

  Todos los métodos de aserción aceptan un argumento msg que, si se especifica, se utiliza como mensaje de error en caso de fallo (véase también `longMessage`). Tenga en cuenta que el argumento de la palabra clave msg puede pasarse a `assertRaises()`, `assertRaisesRegex()`, `assertWarns()`, `assertWarnsRegex()` sólo cuando se utilizan como gestor de contexto.

  `assertEqual`(first, second, msg=None)

    Testea que first y second son iguales. Si los valores no comparan como iguales, el test fallará.

    Además, si first y second son exactamente del mismo tipo y uno de lista, tuple, dict, set, frozenset o str o cualquier tipo que una subclase registre con `addTypeEqualityFunc()` se llamará a la función de igualdad específica del tipo para generar un mensaje de error por defecto más útil (véase también la lista de métodos específicos del tipo).

    Distinto en la versión 3.1: Añadida la llamada automática de la función de igualdad de tipo específico.

    Distinto en la versión 3.2: `assertMultiLineEqual()` añadido como la función por defecto para igualdad de tipos cuando se comparan cadenas.

  `assertNotEqual`(first, second, msg=None)

    Testea que first y second no son iguales. Si los valores son iguales, el test fallará.

  `assertTrue`(expr, msg=None)
  `assertFalse`(expr, msg=None)

    Testea que expr es verdadero (o falso).

    Note que esto es equivalente a `bool(expr) is True` y no a `expr is True` (use `assertIs(expr, True)` para lo último). Este método también debe evitarse cuando se disponga de métodos más específicos (por ejemplo, `assertEqual(a, b)` en lugar de `assertTrue(a == b)`), porque proporcionan un mejor mensaje de error en caso de fallo.

  `assertIs`(first, second, msg=None)
  `assertIsNot`(first, second, msg=None)

    Testea si first y second son (o no) el mismo objeto.

    Nuevo en la versión 3.1.

  `assertIsNone`(expr, msg=None)
  `assertIsNotNone`(expr, msg=None)

    Testea que expr es (o no es) `None`.

    Nuevo en la versión 3.1.

  `assertIn`(member, container, msg=None)
  `assertNotIn`(member, container, msg=None)

    Testea que member está (o no está) en container.

    Nuevo en la versión 3.1.

  `assertIsInstance`(obj, cls, msg=None)
  `assertNotIsInstance`(obj, cls, msg=None)

    Testea que obj es (o no es) una instancia de cls (que puede ser una clase o una tupla de clases, de la misma forma que soporta `isinstance()`). Para chequear por el tipo exacto, use `assertIs(type(obj), cls)`.

    Nuevo en la versión 3.2.

  Es también posible chequear la producción de excepciones, advertencias y mensajes de log usando los siguientes métodos:

  Método | Comprueba que | Nuevo en
  --- | --- | ---
  `assertRaises(exc, fun, *args, **kwds)` | `fun(*args, **kwds)` lanza exc |
  `assertRaisesRegex(exc, r, fun, *args, **kwds)` | `fun(*args, **kwds)` lanza exc y el mensaje coincide con regex r | 3.1
  `assertWarns(warn, fun, *args, **kwds)` | `fun(*args, **kwds)` lanza warn | 3.2
  `assertWarnsRegex(warn, r, fun, *args, **kwds)` | `fun(*args, **kwds)` lanza warn y el mensaje coincide con regex r | 3.2
  `assertLogs(logger, level)` | El bloque `with` vuelca sus logs a logger con el level mínimo | 3.4

  `assertRaises`(exception, callable, *args, **kwds)
  `assertRaises`(exception, *, msg=None)

    Testea que se lanza una excepción cuando se llama a callable con cualquier argumento posicional o de palabra clave que también se pasa a `assertRaises()`. El test pasa si se lanza exception, es un error si se lanza otra excepción, o falla si no se lanza ninguna excepción. Para tener en cuenta cualquiera de un grupo de excepciones, una tupla que contenga las clases de excepción puede ser pasada como exception.

    Si sólo se dan los argumentos de exception y posiblemente msg, retorna un administrador de contexto para que el código testado pueda ser escrito en línea en lugar de como una función:

        with self.assertRaises(SomeException):
            do_something()

    Cuando se emplea como un administrador de contexto, `assertRaises()` acepta el argumento por palabra clave adicional msg.

    El gestor de contexto almacenará el objeto de excepción capturado en su atributo `exception` . Esto puede ser útil si la intención es realizar comprobaciones adicionales sobre la excepción planteada:

        with self.assertRaises(SomeException) as cm:
            do_something()

        the_exception = cm.exception
        self.assertEqual(the_exception.error_code, 3)

    Distinto en la versión 3.1: Añadió la capacidad de usar `assertRaises()` como gestor de contexto.

    Distinto en la versión 3.2: Añadido el atributo `exception` .

    Distinto en la versión 3.3: Añadido el argumento por palabra clave msg cuando se emplea un gestor de contexto.

  `assertRaisesRegex`(exception, regex, callable, *args, **kwds)
  `assertRaisesRegex`(exception, regex, *, msg=None)

    Como `assertRaises()` pero también testea que regex coincide en la representación de la cadena de la excepción planteada. regex puede ser un objeto de expresión regular o una cadena que contiene una expresión regular adecuada para ser usada por `re.search()`. Ejemplos:

        self.assertRaisesRegex(ValueError, "invalid literal for.*XYZ'$",
                               int, 'XYZ')

    o:

        with self.assertRaisesRegex(ValueError, 'literal'):
           int('XYZ')

    Nuevo en la versión 3.1: Añadido bajo el nombre de `assertRaisesRegexp`.

    Distinto en la versión 3.2: Renombrado a `assertRaisesRegex()`.

    Distinto en la versión 3.3: Añadido el argumento por palabra clave msg cuando se emplea un gestor de contexto.

  `assertWarns`(warning, callable, *args, **kwds)
  `assertWarns`(warning, *, msg=None)

    Testea que una advertencia se activa cuando se llama a callable con cualquier argumento posicional o de palabra clave que también se pasa a `assertWarns()`. El test pasa si se activa el warning y falla si no lo hace. Cualquier excepción es un error. Para considerar cualquiera de un grupo de advertencias, una tupla que contenga las clases de advertencia puede ser pasada como warnings.

    Si sólo se dan los argumentos de advertencia y msg, retorna un gestor de contexto para que el código testado pueda ser escrito en línea en lugar de como una función:

        with self.assertWarns(SomeWarning):
            do_something()

    Cuando se usa como gestor de contexto, `assertWarns()` acepta el argumento de palabra clave adicional msg.

    El gestor de contexto almacenará el objeto de advertencia capturado en su atributo `warning`, y la línea del código que disparó las advertencias en los atributos `filename` y `lineno` . Esto puede ser útil si la intención es realizar comprobaciones adicionales sobre la advertencia capturada:

        with self.assertWarns(SomeWarning) as cm:
            do_something()

        self.assertIn('myfile.py', cm.filename)
        self.assertEqual(320, cm.lineno)

    Este método funciona independientemente de los filtros de aviso que estén en su lugar cuando se llame.

    Nuevo en la versión 3.2.

    Distinto en la versión 3.3: Añadido el argumento por palabra clave msg cuando se emplea un gestor de contexto.

  `assertWarnsRegex`(warning, regex, callable, *args, **kwds)
  `assertWarnsRegex`(warning, regex, *, msg=None)

    Como `assertWarns()` pero también testea que regex coincide en el mensaje del aviso disparado. regex puede ser un objeto de expresión regular o una cadena que contiene una expresión regular adecuada para ser usada por `re.search()`. Ejemplo:

        self.assertWarnsRegex(DeprecationWarning,
                              r'legacy_function\(\) is deprecated',
                              legacy_function, 'XYZ')

    o:

        with self.assertWarnsRegex(RuntimeWarning, 'unsafe frobnicating'):
            frobnicate('/etc/passwd')

    Nuevo en la versión 3.2.

    Distinto en la versión 3.3: Añadido el argumento por palabra clave msg cuando se emplea un gestor de contexto.

  `assertLogs`(logger=None, level=None)

    Un gestor de contexto para comprobar que al menos un mensaje está registrado en el logger o en uno de sus hijos, con al menos el level dado.

    Si se da, logger debería ser un objeto `logging.Logger` o un `str` dando el nombre de un logger. El valor por defecto es el root logger, que captará todos los mensajes.

    Si se da, level debe ser un nivel de logging numérico o su equivalente en cadena (por ejemplo, o bien `”ERROR”` o `logging.ERROR`). El valor por defecto es `logging.INFO`.

    El test pasa si al menos un mensaje emitido dentro del bloque `with` coincide con las condiciones de logger y level, de lo contrario falla.

    El objeto devuelto por el gestor de contexto es un ayudante de grabación que lleva un registro de los mensajes de registro que coinciden. Tiene dos atributos:

    `records`

      Una lista de objetos `logging.LogRecord` de los mensajes de log coincidentes.

    `output`

      Una lista de objetos `str` con la salida forrajeada en los mensajes coincidentes.

    Ejemplo:

        with self.assertLogs('foo', level='INFO') as cm:
           logging.getLogger('foo').info('first message')
           logging.getLogger('foo.bar').error('second message')
        self.assertEqual(cm.output, ['INFO:foo:first message',
                                     'ERROR:foo.bar:second message'])

    Nuevo en la versión 3.4.

  Hay también otros métodos empleados para realizar comprobaciones más específicas, tales como:

  Método | Comprueba que | Nuevo en
  --- | --- | ---
  `assertAlmostEqual(a, b)` | `round(a-b, 7) == 0` |
  `assertNotAlmostEqual(a, b)` | `round(a-b, 7) != 0` |
  `assertGreater(a, b)` | `a > b` | 3.1
  `assertGreaterEqual(a, b)` | `a >= b` | 3.1
  `assertLess(a, b)` | `a < b` | 3.1
  `assertLessEqual(a, b)` | `a <= b` | 3.1
  `assertRegex(s, r)` | `r.search(s)` | 3.1
  `assertNotRegex(s, r)` | `not r.search(s)` | 3.2
  `assertCountEqual(a, b)` | a y b tienen los mismos elementos y en el mismo número, sin importar su orden. | 3.2

  `assertAlmostEqual`(first, second, places=7, msg=None, delta=None)
  `assertNotAlmostEqual`(first, second, places=7, msg=None, delta=None)

    Testea que first y second son aproximadamente (o no aproximadamente) iguales calculando su diferencia, redondeando al número dado de puntos places decimales (por defecto 7), y comparado a cero. Nótese que estos métodos redondean los valores al número dado de puntos decimales (por ejemplo como la función `round()`) y no cifras significativas.

    Si se suministra delta en vez de places que entonces la diferencia entre first y second deba ser menor o igual a (o mayor que) delta.

    Suministrar tanto delta como places lanza un `TypeError`.

    Distinto en la versión 3.2: `assertAlmostEqual()` considera automáticamente casi iguales a los objetos que se comparan igual. `assertNotAlmostEqual()` falla automáticamente si los objetos comparan iguales. Añadido el argumento de palabra clave delta.

  `assertGreater`(first, second, msg=None)
  `assertGreaterEqual`(first, second, msg=None)
  `assertLess`(first, second, msg=None)
  `assertLessEqual`(first, second, msg=None)

    Prueba que first es respectivamente >, >=, < o <= que second dependiendo del nombre del método. Si no, el test fallará:

        >>> self.assertGreaterEqual(3, 4)
        AssertionError: "3" unexpectedly not greater than or equal to "4"

    Nuevo en la versión 3.1.

  `assertRegex`(text, regex, msg=None)
  `assertNotRegex`(text, regex, msg=None)

    Testea que una búsqueda regex coincide (o no coincide) con el text. En caso de fallo, el mensaje de error incluirá el patrón y el text (o el patrón y la parte de text que coincida inesperadamente). regex puede ser un objeto de expresión regular o una cadena que contiene una expresión regular adecuada para ser utilizada por `re.search()`.

    Nuevo en la versión 3.1: Añadido bajo el nombre de `assertRegexpMatches`.

    Distinto en la versión 3.2: El método `assertRegexpMatches()` ha sido renombrado a `assertRegex()`.

    Nuevo en la versión 3.2: `assertNotRegex()`.

    Nuevo en la versión 3.5: El nombre `assertNotRegexpMatches` es un alias obsoleto para `assertNotRegex()`.

  `assertCountEqual`(first, second, msg=None)

    Testea que la secuencia first contiene los mismos elementos que second, independientemente de su orden. Cuando no lo hagan, se generará un mensaje de error con las diferencias entre las secuencias.

    Los elementos duplicados no son ignorados cuando se comparan first y second. Verifica si cada elemento tiene la misma cuenta en ambas secuencias. Equivalente a: `assertEqual(Counter(list(first)), Counter(list(second)))` pero funciona también con secuencias de objetos que no son hashable.

    Nuevo en la versión 3.2.

  El método `assertEqual()` envía la comprobación de igualdad de los objetos del mismo tipo a diferentes métodos específicos de tipo. Estos métodos ya están implementados para la mayoría de los tipos incorporados, pero también es posible registrar nuevos métodos usando `addTypeEqualityFunc()`:

  `addTypeEqualityFunc`(typeobj, function)

    Registra un método específico de tipo llamado por `assertEqual()` para comprobar si dos objetos del mismo typeobj (no subclases) comparan como iguales. function debe tomar dos argumentos posicionales y un tercer argumento de palabra clave msg=None tal y como lo hace `assertEqual()`. Debe lanzar `self.failureException(msg)` cuando se detecta una desigualdad entre los dos primeros parámetros, posiblemente proporcionando información útil y explicando las desigualdades en detalle en el mensaje de error.

    Nuevo en la versión 3.1.

  La lista de métodos específicos de tipo utilizados automáticamente por `assertEqual()` se resumen en la siguiente tabla. Tenga en cuenta que normalmente no es necesario invocar estos métodos directamente.

  Método | Usado para comparar | Nuevo en
  --- | --- | ---
  `assertMultiLineEqual(a, b)` | strings | 3.1
  `assertSequenceEqual(a, b)` | sequences | 3.1
  `assertListEqual(a, b)` | lists | 3.1
  `assertTupleEqual(a, b)` | tuples | 3.1
  `assertSetEqual(a, b)` | sets or frozensets | 3.1
  `assertDictEqual(a, b)` | dicts | 3.1

  `assertMultiLineEqual`(first, second, msg=None)

    Testea que la cadena multilínea first es igual a la cadena second. Cuando no sea igual, una diferencia de las dos cadenas que resalte las diferencias se incluirá en el mensaje de error. Este método se utiliza por defecto cuando se comparan cadenas con `assertEqual()`.

    Nuevo en la versión 3.1.

  `assertSequenceEqual`(first, second, msg=None, seq_type=None)

    Testea que dos secuencias son iguales. Si se suministra un seq_type, tanto first como second deben ser instancias de seq_type o se lanzará un fallo. Si las secuencias son diferentes se construye un mensaje de error que muestra la diferencia entre las dos.

    Este método no es llamado directamente por `assertEqual()`, pero se usa para implementar `assertListEqual()` y `assertTupleEqual()`.

    Nuevo en la versión 3.1.

  `assertListEqual`(first, second, msg=None)
  `assertTupleEqual`(first, second, msg=None)

    Testea que dos listas o tuplas son iguales. Si no es así, se construye un mensaje de error que muestra sólo las diferencias entre las dos. También se lanza un error si alguno de los parámetros es del tipo equivocado. Estos métodos se utilizan por defecto cuando se comparan listas o tuplas con `assertEqual()`.

    Nuevo en la versión 3.1.

  `assertSetEqual`(first, second, msg=None)

    Testea que dos conjuntos son iguales. Si no es así, se construye un mensaje de error que enumera las diferencias entre los conjuntos. Este método se utiliza por defecto cuando se comparan los conjuntos o frozensets con `assertEqual()`.

    Falla si cualquiera de first o second no tiene un método de `set.difference()`.

    Nuevo en la versión 3.1.

  `assertDictEqual`(first, second, msg=None)

    Testea que dos diccionarios son iguales. Si no es así, se construye un mensaje de error que muestra las diferencias en los diccionarios. Este método se usará por defecto para comparar los diccionarios en las llamadas a `assertEqual()`.

    Nuevo en la versión 3.1.

  Finalmente, `TestCase` proporciona los siguientes métodos y atributos:

  `fail`(msg=None)

    Señala un fallo del test incondicionalmente, con msg o `None` para el mensaje de error.

  `failureException`

    Este atributo de clase da la excepción lanzada por el método de test. Si un marco de pruebas necesita utilizar una excepción especializada, posiblemente para llevar información adicional, debe subclasificar esta excepción para «jugar limpio» con el marco. El valor inicial de este atributo es `AssertionError`.

  `longMessage`

    Este atributo de clase determina lo que ocurre cuando se pasa un mensaje de fallo personalizado como el argumento msg a una llamada assertXYY que falla. `True` es el valor por defecto. En este caso, el mensaje personalizado se añade al final del mensaje de fallo estándar. Cuando se establece en `False`, el mensaje personalizado reemplaza al mensaje estándar.

    La configuración de la clase puede ser anulada en los métodos de test individuales asignando un atributo de instancia, self.longMessage, a `True` o `False` antes de llamar a los métodos assert.

    La configuración de la clase se reajusta antes de cada llamada de test.

    Nuevo en la versión 3.1.

  `maxDiff`

    Este atributo controla la longitud máxima de las diferencias de salida de métodos assert que reportan diferencias en caso de fallo. El valor predeterminado es de 80*8 caracteres. Los métodos assert afectados por este atributo son `assertSequenceEqual()` (incluyendo todos los métodos de comparación de secuencias que le delegan), `assertDictEqual()` y `assertMultiLineEqual()`.

    Poner `maxDiff` en `None` significa que no hay una longitud máxima de diferencias.

    Nuevo en la versión 3.2.

  Los marcos de test pueden utilizar los siguientes métodos para reunir información sobre el test:

  `countTestCases`()

    Retorna el número de tests representados por este objeto de test. Para las instancias de `TestCase`, este siempre será `1`.

  `defaultTestResult`()

    Retorna una instancia de la clase de resultado de test que debería utilizarse para esta clase de caso de test (si no se proporciona otra instancia de resultado al método `run()`).

    Para las instancias de `TestCase`, ésta siempre será una instancia de `TestResult`; las subclases de `TestCase` deben anular esto según sea necesario.

  `id`()

    Devuelva una cadena que identifique el caso de test específico. Normalmente es el nombre completo del método de test, incluyendo el nombre del módulo y de la clase.

  `shortDescription`()

    Devuelve una descripción de la prueba, o `None` si no se ha proporcionado ninguna descripción. La implementación por defecto de este método devuelve la primera línea de la docstring del método de test, si está disponible, o `None` .

    Distinto en la versión 3.1: En 3.1 esto se cambió para añadir el nombre del test a la descripción corta incluso en presencia de una docstring. Esto causó problemas de compatibilidad con las extensiones de unittest y la adición del nombre de test fue movida a la `TextTestResult` en Python 3.2.

  `addCleanup`(function, /, *args, **kwargs)

    Añade una función que se llamará después de `tearDown()` a los recursos de limpieza utilizados durante el test. Las funciones se llamarán en orden inverso al orden en que se agregan (LIFO). Se llaman con cualquier argumento y argumentos de palabra clave que se pase a `addCleanup()` cuando se agregan.

    Si `setUp()` falla, lo que significa que `tearDown()` no se llama, entonces cualquier función de limpieza añadida seguirá siendo llamada.

    Nuevo en la versión 3.1.

  `doCleanups`()

    Este método se llama incondicionalmente después de `tearDown()`, o después de `setUp()` si `setUp()` lanza una excepción.

    Es responsable de llamar a todas las funciones de limpieza añadidas por `addCleanup()`. Si necesitas que las funciones de limpieza se llamen con anterioridad a `tearDown()` entonces puedes llamar a `doCleanups()` tú mismo.

    `doCleanups()` saca los métodos de la pila de funciones de limpieza uno a uno, así que se puede llamar en cualquier momento.

    Nuevo en la versión 3.1.

  classmethod `addClassCleanup`(function, /, *args, **kwargs)

    Añade una función que se llamará después de `tearDownClass()` para limpiar recursos utilizados durante la clase de test. Las funciones se llamarán en orden inverso al orden en que se agregan (LIFO). Se llaman con cualquier argumento y argumento de palabra clave que se pase a `addClassCleanup()` cuando se añadan.

    Si `setUpClass()` falla, lo que significa que `tearDownClass()` no se invoca, entonces cualquier función de limpieza añadida seguirá siendo llamada.

    Nuevo en la versión 3.8.

  classmethod `doClassCleanups`()

    Este método se llama incondicionalmente después de `tearDownClass()`, o después de `setUpClass()` si `setUpClass()` lanza una excepción.

    Es responsable de llamar a todas las funciones de limpieza añadidas por `addCleanupClass()`. Si necesitas que las funciones de limpieza se llamen con anterioridad a `tearDownClass()` entonces puedes llamar a `doCleanupsClass()` tú mismo.

    `doCleanupsClass()` saca los métodos de la pila de funciones de limpieza de uno en uno, así que se puede llamar en cualquier momento.

    Nuevo en la versión 3.8.

class `unittest.``IsolatedAsyncioTestCase`(methodName='runTest')

  Esta clase proporciona una API similar a `TestCase` y también acepta corutinas como funciones de test.

  Nuevo en la versión 3.8.

  coroutine `asyncSetUp`()

    Método llamado para preparar la configuración de test. Esto se llama después de `setUp()`. Se llama inmediatamente antes de llamar al método de test; aparte de `AssertionError` o `SkipTest`, cualquier excepción lanzada por este método se considerará un error más que un fallo del test. La implementación por defecto no hace nada.

  coroutine `asyncTearDown`()

    Método llamado inmediatamente después de que se haya llamado el método de test y se haya registrado el resultado. Esto se llama antes de `tearDown()`. Se llama así aunque el método de test haya lanzado una excepción, por lo que la implementación en las subclases puede necesitar ser particularmente cuidadosa en la comprobación del estado interno. Cualquier excepción, que no sea `AssertionError` o `SkipTest`, lanzada por este método se considerará un error adicional en lugar de un fallo del test (aumentando así el número total de errores reportados). Este método sólo se llamará si `asyncSetUp()` tiene éxito, independientemente del resultado del método de test. La implementación por defecto no hace nada.

  `addAsyncCleanup`(function, /, *args, **kwargs)

    Este método acepta una corutina que puede ser utilizada como función de limpieza.

  `run`(result=None)

    Establece un nuevo bucle de eventos para ejecutar el test, recogiendo el resultado en el objeto `TestResult` pasado como result. Si se omite result o `None`, se crea un objeto resultado temporal (llamando al método `defaultTestResult()`) y se utiliza. El objeto resultante se devuelve al invocado de `run()`. Al final del test se cancelan todas las tareas del bucle de eventos.

  Un ejemplo ilustrando el orden:

      from unittest import IsolatedAsyncioTestCase

      events = []

      class Test(IsolatedAsyncioTestCase):

          def setUp(self):
              events.append("setUp")

          async def asyncSetUp(self):
              self._async_connection = await AsyncConnection()
              events.append("asyncSetUp")

          async def test_response(self):
              events.append("test_response")
              response = await self._async_connection.get("https://example.com")
              self.assertEqual(response.status_code, 200)
              self.addAsyncCleanup(self.on_cleanup)

          def tearDown(self):
              events.append("tearDown")

          async def asyncTearDown(self):
              await self._async_connection.close()
              events.append("asyncTearDown")

          async def on_cleanup(self):
              events.append("cleanup")

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

  Después de ejecutar el test, `events` contendría `[“setUp”, “asyncSetUp”, “test_response”, “asyncTearDown”, “tearDown”, “cleanup”]`.

class `unittest.``FunctionTestCase`(testFunc, setUp=None, tearDown=None, description=None)

  Esta clase implementa la porción de la interfaz `TestCase` que permite al corredor de tests conducir los tests, pero no proporciona los métodos que el código de test puede utilizar para comprobar e informar de los errores. Se utiliza para crear casos de test utilizando código de prueba heredado, lo que permite que se integre en un marco de tests basado en `unittest`.

#### Alias obsoletos

Por razones históricas, algunos de los métodos de `TestCase` tenían uno o más alias que ahora están obsoletos. La siguiente tabla lista los nombres correctos junto con sus alias obsoletos:

> Nombre del método | Alias deprecado | Alias deprecado
> --- | --- | ---
> `assertEqual()` | failUnlessEqual | assertEquals
> `assertNotEqual()` | failIfEqual | assertNotEquals
> `assertTrue()` | failUnless | assert_
> `assertFalse()` | failIf |
> `assertRaises()` | failUnlessRaises |
> `assertAlmostEqual()` | failUnlessAlmostEqual | assertAlmostEquals
> `assertNotAlmostEqual()` | failIfAlmostEqual | assertNotAlmostEquals
> `assertRegex()` |  | assertRegexpMatches
> `assertNotRegex()` |  | assertNotRegexpMatches
> `assertRaisesRegex()` |  | assertRaisesRegexp

> Obsoleto desde la versión 3.1: Los alias de fail* que figuran en la segunda columna han sido declarados obsoletos.

> Obsoleto desde la versión 3.2: Los alias de aserción* que figuran en la tercera columna han sido declarados obsoletos.

> Obsoleto desde la versión 3.2: `assertRegexpMatches` y `assertRaisesRegexp` han sido renombrados a `assertRegex()` y `assertRaisesRegex()`.

> Obsoleto desde la versión 3.5: El nombre `assertNotRegexpMatches` se ha declarado obsoleto en favor de `assertNotRegex()`.

### Agrupando tests

class `unittest.``TestSuite`(tests=())

  Esta clase representa una agregación de casos de test individuales y conjuntos de tests. La clase presenta la interfaz que necesita el corredor de tests para poder ser ejecutado como cualquier otro caso de test. Ejecutar una instancia `TestSuite` es lo mismo que iterar sobre el conjunto, ejecutando cada test individualmente.

  Si se indican tests, debe ser un iterable de casos de test individuales u otros conjuntos de tests que se usarán para construir el conjunto inicialmente. Se proporcionan métodos adicionales para añadir casos de test y conjuntos a la colección más adelante.

  Los objetos de `TestSuite` se comportan de manera muy parecida a los objetos de `TestCase`, excepto que no implementan un test. En cambio, se usan para agregar tests en grupos de tests que deben ser ejecutados juntos. Existen algunos métodos adicionales para agregar tests a las instancias de `TestSuite`:

  `addTest`(test)

    Añade un `TestCase` o `TestSuite` al conjunto.

  `addTests`(tests)

    Añade todos los tests de un iterable de `TestCase` y `TestSuite` a este conjunto de tests.

    Esto equivale a iterar sobre tests, llamando a `addTest()` para cada elemento.

  `TestSuite` comparte los siguientes métodos con `TestCase`:

  `run`(result)

    Ejecuta los tests asociados a este conjunto, recogiendo el resultado en el objeto de resultado del test pasado como result. Tenga en cuenta que a diferencia de `TestCase.run()`, `TestSuite.run()` requiere que se pase el objeto resultado.

  `debug`()

    Ejecuta los tests asociados con este conjunto sin recoger los resultados. Esto permite que las excepciones lanzadas por este test sean propagadas al invocador y puedes ser usadas para apoyar tests que están ejecutándose con un debugger.

  `countTestCases`()

    Retorna el numero de tests representados por este objeto de test, incluidos todos los test individuales y los sub-conjuntos.

  `__iter__`()

    Los tests agrupados por una `TestSuite` se acceden siempre por iteración. Las subclases pueden proporcionar tests anulando `__iter__()`. Tenga en cuenta que este método puede ser invocado varias veces en un mismo conjunto (por ejemplo, cuando se cuentan los tests o se comparan por igualdad), por lo que los tests retornados por iteraciones repetidas antes de `TestSuite.run()` deben ser los mismos para cada iteración de invocación. Después de `TestSuite.run()`, los invocados no deben confiar en los tests retornados por este método a menos que el invocado utilice una subclase que anule `TestSuite._removeTestAtIndex()` para preservar las referencias de los tests.

    Distinto en la versión 3.2: En versiones anteriores la `TestSuite` accedía a los test directamente en lugar de a través de la iteración, por lo que anular `__iter__()` no era suficiente para proporcionar los tests.

    Distinto en la versión 3.4: En versiones anteriores, la `TestSuite` tenía referencias a cada `TestCase` después de `TestSuite.run()`. Las subclases pueden restaurar ese comportamiento anulando `TestSuite._removeTestAtIndex()`.

  En el uso típico de un objeto `TestSuite`, el método `run()` es invocado por un `TestRunner` en lugar de por el marco de test de pruebas automático del usuario final.

### Cargando y ejecutando tests

class `unittest.``TestLoader`

  La clase `TestLoader` se utiliza para crear conjuntos de tests a partir de clases y módulos. Normalmente, no es necesario crear una instancia de esta clase; el módulo `unittest` proporciona una instancia que puede ser compartida como `unittest.defaultTestLoader`. Sin embargo, el uso de una subclase o instancia permite la personalización de algunas propiedades configurables.

  Los objetos `TestLoader` tienen los siguientes atributos:

  `errors`

    Una lista de los errores no fatales encontrados durante los tests de carga. No reseteados por el cargador en ningún momento. Los errores fatales son señalados por el método relevante que lanza una excepción al invocador. Los errores no fatales también son indicados por una prueba sintética que lanzará el error original cuando se ejecute.

    Nuevo en la versión 3.5.

  Los objetos `TestLoader` tienen los siguientes métodos:

  `loadTestsFromTestCase`(testCaseClass)

    Devuelve un conjunto de todos los casos de test contenidos en la `TestCase`derivada de `testCaseClass`.

    Se crea una instancia de caso de test para cada método nombrado por `getTestCaseNames()`. Por defecto, estos son los nombres de los métodos que comienzan con `test`. Si `getTestCaseNames()` no retorna ningún método, pero se implementa el método `runTest()`, se crea un único caso de test para ese método.

  `loadTestsFromModule`(module, pattern=None)

    Devuelva un conjunto de todos los casos de test contenidos en el módulo dado. Este método busca en module clases derivadas de `TestCase` y crea una instancia de la clase para cada método de test definido para la clase.

    Nota

    Aunque el uso de una jerarquía de clases derivadas de `TestCase` puede ser conveniente para compartir configuraciones y funciones de ayuda, la definición de métodos de test en clases base que no están destinadas a ser instanciadas directamente no complementa bien con este método. Hacerlo, sin embargo, puede ser útil cuando las configuraciones son diferentes y están definidas en subclases.

    Si un módulo proporciona una función `load_tests` será llamado para cargar los tests. Esto permite a los módulos personalizar la carga de los tests. Este es el load_tests protocol. El argumento pattern se pasa como tercer argumento a `load_tests`.

    Distinto en la versión 3.2: Se ha añadido soporte para `load_tests`.

    Distinto en la versión 3.5: El argumento por defecto use_load_tests no documentado y no oficial es obsoleto e ignorado, aunque sigue siendo aceptado por la retrocompatibilidad. El método también acepta ahora un argumento de sólo palabra clave pattern que se pasa a `load_tests` como tercer argumento.

  `loadTestsFromName`(name, module=None)

    Retorna un conjunto de todos los casos de test dado un especificador de cadena.

    El especificador name es un «nombre punteado» que puede resolverse ya sea a un módulo, una clase de caso de test, un método de test dentro de una clase de caso de test, una instancia `TestSuite`, o un objeto invocable que devuelve una instancia `TestCase` o `TestSuite`. Estas comprobaciones se aplican en el orden que se indica aquí; es decir, un método en una posible clase de caso de test se recogerá como «un método de test dentro de una clase de caso de test”, en lugar de «un objeto invocable”.

    Por ejemplo, si tiene un módulo `SampleTests` que contiene una clase derivada de `TestCase` `SampleTestCase` con tres métodos de test (`test_one()`, `test_two()`, y `test_three()`), el especificador `SampleTests.SampleTestCase'` haría que este método devolviera una suite que ejecutara los tres métodos de prueba. El uso del especificador `SampleTests.SampleTestCase.test_two'` provocaría que este método devolviera una suite de tests que ejecutaría sólo el método de test `test_two()`. El especificador puede referirse a los módulos y paquetes que no han sido importados; serán importados como un efecto secundario.

    El método opcionalmente resuelve name relativo al module dado.

    Distinto en la versión 3.5: Si un `ImportError` o `AttributeError` ocurre mientras atraviesa name entonces se devolverá un test sintético que lanza ese error cuando se ejecuta. Estos errores están incluidos en los errores acumulados por self.errors.

  `loadTestsFromNames`(names, module=None)

    Similar a `loadTestsFromName()`, pero toma una secuencia de nombres en lugar de un solo nombre. El valor de retorno es una suite de tests que soporta todos los test definidos para cada nombre.

  `getTestCaseNames`(testCaseClass)

    Devuelve una secuencia ordenada de nombres de métodos encontrados dentro de testCaseClass; esta debería ser una subclase de `TestCase`.

  `discover`(start_dir, pattern='test*.py', top_level_dir=None)

    Encuentra todos los módulos de prueba recurriendo a subdirectorios del directorio de inicio especificado, y retorna un objeto de TestSuite que los contenga. Sólo se cargarán los archivos de test que coincidan con el pattern. (Utilizando la coincidencia de patrones de estilo de shell.) Sólo se cargarán los nombres de los módulos que sean importables (es decir, que sean identificadores Python válidos).

    Todos los módulos de test deben ser importables desde el nivel superior del proyecto. Si el directorio de inicio no es el directorio de nivel superior, entonces el directorio de nivel superior debe ser especificado por separado.

    Si la importación de un módulo falla, por ejemplo debido a un error de sintaxis, entonces esto se registrará como un error único y el descubrimiento continuará. Si el fallo en la importación se debe a que `SkipTest` se ha lanzado, se registrará como un salto en lugar de un error.

    Si se encuentra un paquete (un directorio que contiene un archivo llamado `__init__.py`), se comprobará si el paquete tiene una función `load_tests`. Si existe, entonces se invocará `package.load_tests(loader, tests, pattern)`. Test discovery se encarga de asegurar que un paquete sólo se comprueba una vez durante una invocación, incluso si la propia función load_tests llama a `loader.discover`.

    Si `load_tests` existe, entonces el descubrimiento no recurre en el paquete, `load_tests` es responsable de cargar todos los tests en el paquete.

    El patrón no se almacena deliberadamente como atributo cargador para que los paquetes puedan continuar descubriéndose a sí mismos. top_level_dir se almacena de forma que `load_tests` no necesita pasar este argumento a `loader.discover()`.

    start_dir puede ser un nombre de módulo punteado así como un directorio.

    Nuevo en la versión 3.2.

    Distinto en la versión 3.4: Los módulos que lanzan `SkipTest` en la importación se registran como saltos, no como errores.

    Distinto en la versión 3.4: start_dir puede ser un paquete de espacios de nombres.

    Distinto en la versión 3.4: Las rutas se ordenan antes de ser importadas para que el orden de ejecución sea el mismo, incluso si el orden del sistema de archivos subyacente no depende del nombre del archivo.

    Distinto en la versión 3.5: Los paquetes encontrados son ahora comprobados para `load_tests` sin importar si su ruta coincide con el pattern, porque es imposible que el nombre de un paquete coincida con el patrón por defecto.

  Los siguientes atributos de un `TestLoader` pueden ser configurados ya sea por subclasificación o asignación en una instancia:

  `testMethodPrefix`

    Cadena que da el prefijo de los nombres de métodos que serán interpretados como métodos de test. El valor por defecto es `'test'`.

    Esto afecta a `getTestCaseNames()` y a todos los métodos `loadTestsFrom*()` .

  `sortTestMethodsUsing`

    Función que se utiliza para comparar los nombres de los métodos al clasificarlos en `getTestCaseNames()` y todos los métodos `loadTestsFrom*()`.

  `suiteClass`

    Objeto invocable que construye un conjunto de pruebas a partir de una lista de pruebas. No se necesitan métodos en el objeto resultante. El valor por defecto es la clase `TestSuite`.

    Esto afecta a todos los métodos `loadTestsFrom*()`.

  `testNamePatterns`

    Lista de patrones de nombres de test de comodines al estilo del shell de Unix que los métodos de test tienen que coincidir con para ser incluidos en las suites de test (ver opción `-v`).

    Si este atributo no es `None` (el predeterminado), todos los métodos de test que se incluyan en los paquetes de test deben coincidir con uno de los patrones de esta lista. Tenga en cuenta que las coincidencias se realizan siempre utilizando `fnmatch.fnmatchcase()`, por lo que a diferencia de los patrones pasados a la opción `-v`, los patrones de subcadena simple tendrán que ser convertidos utilizando los comodines `*`.

    Esto afecta a todos los métodos `loadTestsFrom*()`.

    Nuevo en la versión 3.7.

class `unittest.``TestResult`

  Esta clase se utiliza para recopilar información sobre qué tests han tenido éxito y cuáles han fracasado.

  Un objeto `TestResult` almacena los resultados de una serie de pruebas. Las clases `TestCase` y `TestSuite` aseguran que los resultados se registren correctamente; los autores de los tests no tienen que preocuparse de registrar el resultado de las mismas.

  Los marcos de pruebas construidos sobre `unittest` pueden querer acceder al objeto `TestResult` generado por la ejecución de un conjunto de tests con fines de reporte; una instancia `TestResult` es devuelta por el método `TestRunner.run()` para este propósito.

  Las instancias de `TestResult` tienen los siguientes atributos que serán de interés cuando se inspeccionen los resultados de la ejecución de un conjunto de tests:

  `errors`

    Una lista que contiene 2 tuplas de instancias `TestCase` y cadenas con formato de tracebacks. Cada tupla representa una prueba que lanzó una excepción inesperada.

  `failures`

    Una lista que contiene 2 tuplas de instancias `TestCase` y cadenas con formato de traceback. Cada tupla representa un test en el que un fallo fue explícitamente señalado usando los métodos `TestCase.assert*()`.

  `skipped`

    Una lista que contiene 2 tuplas de instancias de `TestCase` y cadenas que contienen la razón para saltarse el test.

    Nuevo en la versión 3.1.

  `expectedFailures`

    Una lista que contiene 2 tuplas de instancias `TestCase` y cadenas con formato de traceback. Cada tupla representa un fallo esperado del caso de test.

  `unexpectedSuccesses`

    Una lista que contiene instancias de `TestCase` que fueron marcadas como fracasos esperados, pero tuvieron éxito.

  `shouldStop`

    Puesto en `True` cuando la ejecución de los tests se detenga por `stop()`.

  `testsRun`

    El número total de tests realizados hasta ahora.

  `buffer`

    Si se ajusta a true, `sys.stdout` y `sys.stderr` serán almacenados entre `startTest()` y `stopTest()` siendo llamados. La salida recolectada sólo tendrá eco en el verdadero `sys.stdout` y `sys.stderr` si la prueba falla o se equivoca. Cualquier salida también se adjunta al mensaje de fallo / error.

    Nuevo en la versión 3.2.

  `failfast`

    Si se ajusta a true `stop()` se llamará al primer fallo o error, deteniendo la ejecución de la prueba.

    Nuevo en la versión 3.2.

  `tb_locals`

    Si se ajusta a true entonces las variables locales se mostrarán en los tracebacks.

    Nuevo en la versión 3.5.

  `wasSuccessful`()

    Devuelve `True` si todas las pruebas realizadas hasta ahora han pasado, de lo contrario devuelve `False`.

    Distinto en la versión 3.4: Devuelve `False` si hubo algún `unexpectedSuccesses` de las pruebas marcadas con el decorador `expectedFailure()`.

  `stop`()

    Este método puede ser llamado para señalar que el conjunto de pruebas que se están ejecutando debe ser abortado poniendo el atributo `shouldStop` en `True`. `TestRunner` los objetos deben respetar esta bandera y regresar sin ejecutar ninguna prueba adicional.

    Por ejemplo, esta característica es utilizada por la clase `TextTestRunner` para detener el marco de pruebas cuando el usuario señala una interrupción desde el teclado. Las herramientas interactivas que proporcionan implementaciones de `TestRunner` pueden usar esto de manera similar.

  Los siguientes métodos de la clase `TestResult` se utilizan para mantener las estructuras de datos internos, y pueden ampliarse en subclases para apoyar los requisitos de información adicionales. Esto es particularmente útil para construir herramientas que apoyen la presentación de informes interactivos mientras se ejecutan las pruebas.

  `startTest`(test)

    Llamado cuando el caso de prueba test está a punto de ser ejecutado.

  `stopTest`(test)

    Llamado después de que el caso de prueba prueba haya sido ejecutado, independientemente del resultado.

  `startTestRun`()

    Llamado una vez antes de que se ejecute cualquier prueba.

    Nuevo en la versión 3.1.

  `stopTestRun`()

    Llamado una vez después de que se ejecuten todas las pruebas.

    Nuevo en la versión 3.1.

  `addError`(test, err)

    Llamado cuando el caso de prueba test plantea una excepción inesperada. err es una tupla de la forma devuelta por `sys.exc_info()`: `(type, value, traceback)`.

    La implementación por defecto añade una tupla `(test, formatted_err)` al atributo `errors` de la instancia, donde formatted_err es una traza formateada derivada de err.

  `addFailure`(test, err)

    Llamado cuando el caso de prueba test señala un fallo. err es una tupla de la forma devuelta por `sys.exc_info()`: `(type, value, traceback)`.

    La implementación por defecto añade una tupla `(test, formatted_err)` al atributo `failures` de la instancia, donde formatted_err es una traza formateada derivada de err.

  `addSuccess`(test)

    Llamado cuando el caso de prueba test tenga éxito.

    La implementación por defecto no hace nada.

  `addSkip`(test, reason)

    Llamado cuando se salta el caso de prueba test. reason es la razón que la prueba dio para saltarse.

    La implementación por defecto añade una tupla `(test, reason)` al atributo `skipped` de la instancia.

  `addExpectedFailure`(test, err)

    Llamó cuando el caso de prueba test falla, pero fue marcado con el decorador `expectedFailure()`.

    La implementación por defecto añade una tupla `(test, formatted_err)` al atributo `expectedFailures` de la instancia, donde formatted_err es una traza formateada derivada de err.

  `addUnexpectedSuccess`(test)

    Llamó cuando el caso de prueba test se marcó con el decorador `expectedFailure()`, pero tuvo éxito.

    La implementación por defecto añade la prueba al atributo `unexpectedSuccesses` de la instancia.

  `addSubTest`(test, subtest, outcome)

    Llamado cuando termina una subtest. test es el caso de prueba correspondiente al método de test. subtest es una instancia personalizada `TestCase` que describe el test.

    Si outcome es `None`, el subtest tuvo éxito. De lo contrario, falló con una excepción en la que outcome es una tupla de la forma devuelta por `sys.exc_info()`: `(type, value, traceback)`.

    La implementación por defecto no hace nada cuando el resultado es un éxito, y registra los fallos del subtest como fallos normales.

    Nuevo en la versión 3.4.

class `unittest.``TextTestResult`(stream, descriptions, verbosity)

  Una implementación concreta de `TestResult` utilizado por el `TextTestRunner`.

  Nuevo en la versión 3.2: Esta clase se llamaba anteriormente `_TextTestResult`. El antiguo nombre todavía existe como un alias pero está obsoleto.

`unittest.``defaultTestLoader`

  Instancia de la clase `TestLoader` destinada a ser compartida. Si no es necesario personalizar la clase `TestLoader`, esta instancia puede utilizarse en lugar de crear repetidamente nuevas instancias.

class `unittest.``TextTestRunner`(stream=None, descriptions=True, verbosity=1, failfast=False, buffer=False, resultclass=None, warnings=None, *, tb_locals=False)

  Una implementación básica del test runner que produce resultados en una corriente. Si stream es `None`, el valor por defecto, `sys.stderr` se utiliza como flujo de salida. Esta clase tiene unos pocos parámetros configurables, pero es esencialmente muy simple. Las aplicaciones gráficas que ejecutan las suites de prueba deben proporcionar implementaciones alternativas. Tales implementaciones deberían aceptar `**kwargs` como interfaz para construir los cambios de los corredores cuando se añaden características a unittest.

  Por defecto este runner muestra `DeprecationWarning`, `PendingDeprecationWarning`, `ResourceWarning` y `ImportWarning` aunque estén ignorados por defecto. Las advertencias de deprecación causadas por métodos deprecated unittest también tienen un caso especial y, cuando los filtros de advertencia están `'default'` o `'always'`, aparecerán sólo una vez por módulo, para evitar demasiados mensajes de advertencia. Este comportamiento puede ser anulado usando las opciones `-Wd` o `-Wa` de Python (ver Control de advertencias) y dejando warnings a `None`.

  Distinto en la versión 3.2: Añadió el argumento `warnings`.

  Distinto en la versión 3.2: El flujo por defecto está configurado como `sys.stderr` en tiempo de instanciación en lugar de tiempo de importación.

  Distinto en la versión 3.5: Añadido el parámetro tb_locals.

  `_makeResult`()

    Este método devuelve la instancia de `TestResult` usada por `run()`. No está destinado a ser llamado directamente, pero puede ser anulado en subclases para proporcionar un `TestResult` personalizado.

    `_makeResult()` instanciando la clase o el pasaje llamado en el constructor `TextTestRunner` como el argumento de `resultclass`. Por defecto es `TextTestResult` si no se proporciona ninguna `resultclass`. La clase de resultado se instanciará con los siguientes argumentos:

        stream, descriptions, verbosity

  `run`(test)

    Este método es la principal interfaz pública del `TextTestRunner`. Este método toma una instancia `TestSuite` o `TestCase`. Se crea una `TestResult` llamando a `_makeResult()` y se ejecuta(n) la(s) prueba(s) y se imprimen los resultados a stdout.

`unittest.``main`(module='__main__', defaultTest=None, argv=None, testRunner=None, testLoader=unittest.defaultTestLoader, exit=True, verbosity=1, failfast=None, catchbreak=None, buffer=None, warnings=None)

  Un programa de línea de comandos que carga un conjunto de pruebas de módulo y las ejecuta; esto es principalmente para hacer los módulos de prueba convenientemente ejecutables. El uso más simple de esta función es incluir la siguiente línea al final de un guión de prueba:

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

  Puedes hacer pruebas con información más detallada pasando el argumento de la verbosity:

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

  El argumento defaultTest es el nombre de una prueba única o un iterable de nombres de pruebas a ejecutar si no se especifican nombres de pruebas a través de argv. Si no se especifica o `Ninguno` y no se proporcionan nombres de pruebas vía argv, se ejecutan todas las pruebas encontradas en modulo.

  El argumento argv puede ser una lista de opciones pasadas al programa, siendo el primer elemento el nombre del programa. Si no se especifica o `Ninguno`, se utilizan los valores de `sys.argv`.

  El argumento testRunner puede ser una clase de corredor de prueba o una instancia ya creada de él. Por defecto `main` llama `sys.exit()` con un código de salida que indica el éxito o el fracaso de la ejecución de las pruebas.

  El argumento testLoader tiene que ser una instancia `TestLoader`, y por defecto `defaultTestLoader`.

  `main` apoya el uso del intérprete interactivo pasando el argumento `exit=False`. Esto muestra el resultado en la salida estándar sin llamar a `sys.exit()`:

      >>> from unittest import main
      >>> main(module='test_module', exit=False)

  Los parámetros failfast, catchbreak y buffer tienen el mismo efecto que las command-line options del mismo nombre.

  El argumento warnings especifica el filtro de aviso que debe ser usado mientras se realizan los tests. Si no se especifica, permanecerá como `None` si se pasa una opción `-W` a python (ver Warning control), de lo contrario se establecerá como `’default’`.

  Invocar `main` en realidad devuelve una instancia de la clase `TestProgram`. Esto almacena el resultado de las pruebas ejecutadas como el atributo `result`.

  Distinto en la versión 3.1: El parámetro exit fue añadido.

  Distinto en la versión 3.2: Los parámetros verbosity, failfast, catchbreak, buffer y warnings fueron añadidos.

  Distinto en la versión 3.4: El parámetro defaultTest fue cambiado para aceptar también un iterable de nombres de pruebas.

#### load_tests protocolo

Nuevo en la versión 3.2.

Los módulos o paquetes pueden personalizar la forma en que se cargan las pruebas a partir de ellos durante las ejecuciones de prueba normales o el descubrimiento de pruebas mediante la implementación de una función llamada `load_tests`.

Si un módulo de tests define `load_tests` será llamado por `TestLoader.loadTestsFromModule()` con los siguientes argumentos:

    load_tests(loader, standard_tests, pattern)

donde pattern se pasa directamente desde `loadTestsFromModule`. Por defecto es `None`.

Debe retornar una `TestSuite`.

loader es la instancia de `TestLoader` haciendo la carga. standard_tests son los tests que se cargarían por defecto desde el módulo. Es común que los módulos de test sólo quieran añadir o quitar tests del conjunto de tests estándar. El tercer argumento se usa cuando se cargan paquetes como parte del descubrimiento de tests.

Una típica función de `load_tests` que carga pruebas de un conjunto específico de `TestCase`class:`TestCase` puede ser como:

    test_cases = (TestCase1, TestCase2, TestCase3)

    def load_tests(loader, tests, pattern):
        suite = TestSuite()
        for test_class in test_cases:
            tests = loader.loadTestsFromTestCase(test_class)
            suite.addTests(tests)
        return suite

Si discovery se inicia en un directorio que contiene un paquete, ya sea desde la línea de comandos o llamando a `TestLoader.discover()`, entonces el paquete `__init__.py` se comprobará por `load_tests`. Si esa función no existe, discover se reincorporará al paquete como si fuera un directorio más. De lo contrario, el descubrimiento de los tests del paquete se dejará en `load_tests` que se llama con los siguientes argumentos:

    load_tests(loader, standard_tests, pattern)

Esto debería devolver un `TestSuite` que represente todas las pruebas del paquete. (`test_estándar` sólo contendrá las pruebas recogidas de `__init__.py`.)

Debido a que el patrón se pasa a `load_tests` el paquete es libre de continuar (y potencialmente modificar) el descubrimiento de pruebas. Una función de “no hace nada” `load_test` para un paquete de pruebas se vería como:

    def load_tests(loader, standard_tests, pattern):
        # top level directory cached on loader instance
        this_dir = os.path.dirname(__file__)
        package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
        standard_tests.addTests(package_tests)
        return standard_tests

Distinto en la versión 3.5: Discovery ya no comprueba si los nombres de los paquetes coinciden con el patrón debido a la imposibilidad de que los nombres de los paquetes coincidan con el patrón por defecto.

## Instalaciones para clases y módulos

Los accesorios de nivel de clase y módulo se implementan en `TestSuite`. Cuando el conjunto de pruebas se encuentra con una prueba de una nueva clase entonces se llama `tearDownClass()` de la clase anterior (si existe), seguido de `setUpClass()` de la nueva clase.

Del mismo modo, si una prueba es de un módulo diferente de la prueba anterior, entonces se ejecuta `DesmontarMódulo` del módulo anterior, seguido de `DesmontarMódulo` del nuevo módulo.

Después de todas las pruebas, se ejecutan los últimos `tearDownClass` y `tearDownModule`.

Tenga en cuenta que los accesorios compartidos no juegan bien con las características [potenciales] como la paralelización de la prueba y rompen el aislamiento de la prueba. Deben ser usados con cuidado.

El orden por defecto de las pruebas creadas por los cargadores de pruebas unitarias es agrupar todas las pruebas de los mismos módulos y clases. Esto llevará a que `setUpClass` / `setUpModule` (etc) sea llamado exactamente una vez por clase y módulo. Si se aleatoriza el orden, de manera que las pruebas de diferentes módulos y clases sean adyacentes entre sí, entonces estas funciones compartidas de fixture pueden ser llamadas varias veces en una sola ejecución de prueba.

Los accesorios compartidos no están pensados para trabajar con suites con pedidos no estándar. Todavía existe una `BaseTestSuite` para los marcos de trabajo que no quieren soportar accesorios compartidos.

Si hay alguna excepción planteada durante una de las funciones compartidas del aparato, la prueba se notifica como un error. Debido a que no hay una instancia de prueba correspondiente, se crea un objeto `_ErrorHolder` (que tiene la misma interfaz que un `TestCase`) para representar el error. Si sólo estás usando el standard unittest test runner entonces este detalle no importa, pero si eres un autor de marcos de trabajo puede ser relevante.

### setUpClass y tearDownClass

Estos deben ser implementados como métodos de clase:

    import unittest

    class Test(unittest.TestCase):
        @classmethod
        def setUpClass(cls):
            cls._connection = createExpensiveConnectionObject()

        @classmethod
        def tearDownClass(cls):
            cls._connection.destroy()

Si quieres que se invoque a `SetUpClass` y `BreakdownClass` en clases base, debes llamarlos tú mismo. Las implementaciones en `TestCase` están vacías.

Si se lanza una excepción durante una `setUpClass`, entonces los tests de la clase no se ejecutan y la `tearDownClass` no se ejecuta. Las clases que se salten no tendrán `setUpClass` o `tearDownClass`. Si la excepción es una `SkipTest` entonces la clase será reportada como salteada en lugar de como un error.

### setUpModule y tearDownModule

Estos deben ser implementados como funciones:

    def setUpModule():
        createConnection()

    def tearDownModule():
        closeConnection()

Si se lanza una excepción en un `setUpModule`, entonces no se ejecutará ninguna de las pruebas del módulo y no se ejecutará el `tearDownModule`. Si la excepción es una `SkipTest` entonces el módulo será reportado como saltado en lugar de como un error.

Para agregar código de limpieza que se debe ejecutar incluso en el caso de una excepción, utilice `addModuleCleanup`:

`unittest.``addModuleCleanup`(function, /, *args, **kwargs)

  Añade una función que se llamará después de `tearDownModule()` para limpiar los recursos utilizados durante la clase de test. Las funciones se llamarán en orden inverso al orden en que se agregan (LIFO). Se llaman con cualquier argumento y palabra clave que se pase a `addModuleCleanup()` cuando se añadan.

  Si `setUpModule()` falla, lo que significa que `tearDownModule()` no se invoca, entonces cualquier función de limpieza añadida seguirá siendo invocada.

  Nuevo en la versión 3.8.

`unittest.``doModuleCleanups`()

  Esta función se llama incondicionalmente después de `tearDownModule()`, o después de `setUpModule()` si `setUpModule()` lanza una excepción.

  It is responsible for calling all the cleanup functions added by `addModuleCleanup()`. If you need cleanup functions to be called prior to `tearDownModule()` then you can call `doModuleCleanups()` yourself.

  `doModuleCleanups()` saca los métodos de la pila de funciones de limpieza uno a uno, así que se puede llamar en cualquier momento.

  Nuevo en la versión 3.8.

## Manejo de señales

Nuevo en la versión 3.2.

La opción `-c/--catch` línea de comando para unittest, junto con el parámetro `catchbreak` de `unittest.main()`, proporcionan un manejo más amigable del control-C durante una prueba. Con el comportamiento catch break habilitado, control-C permitirá que se complete la prueba que se está ejecutando actualmente, y la ejecución de la prueba terminará y reportará todos los resultados hasta ahora. Un segundo control-C lanzará una `KeyboardInterrupt` de la manera habitual.

El manejador de señales de manejo de control-c intenta permanecer compatible con el código o las pruebas que instalan su propio manejador `signal.SIGINT` . Si se llama al manejador `unittest` pero no es el manejador `signal.SIGINT` instalado, es decir, ha sido reemplazado por el sistema bajo test y delegado, entonces llama al manejador por defecto. Este será normalmente el comportamiento esperado por el código que reemplaza un manejador instalado y delega en él. Para las pruebas individuales que necesiten el manejo de control-c de `unittest` deshabilitado se puede usar el decorador `removeHandler()`.

Hay algunas funciones de utilidad para que los autores de marcos de trabajo habiliten la funcionalidad de control de control-c dentro de los marcos de prueba.

`unittest.``installHandler`()

  Instala el controlador de control-c. Cuando se recibe una `signal.SIGINT` (normalmente en respuesta a que el usuario presione control-c) todos los resultados registrados tienen `stop()` llamado.

`unittest.``registerResult`(result)

  Registrar un objeto `TestResult` para el manejo de control-c. El registro de un resultado almacena una referencia débil a él, por lo que no evita que el resultado sea recogido por el recolector de basura.

  El registro de un objeto `TestResult` no tiene efectos secundarios si el manejo de control-c no está habilitado, por lo que los marcos de pruebas pueden registrar incondicionalmente todos los resultados que crean independientemente de si el manejo está habilitado o no.

`unittest.``removeResult`(result)

  Elimine un resultado registrado. Una vez que un resultado ha sido eliminado, `stop()` ya no se llamará en ese objeto de resultado en respuesta a un control-c.

`unittest.``removeHandler`(function=None)

  Cuando se llama sin argumentos, esta función quita el gestor control-c si se ha instalado. Esta función también se puede utilizar como decorador de tests para quitar temporalmente el controlador mientras se ejecuta el test:

      @unittest.removeHandler
      def test_signal_handling(self):
          ...