prueba: en línea en la nube

PROGRAMA:

NOMBRE

prueba - ejecutar pruebas unitarias

SINOPSIS

juicio [ opciones ] [ presentar | PARA DOS | módulo | Caso de prueba | método de prueba ]

juicio --ayuda | -h

DESCRIPCIÓN

prueba carga y ejecuta un conjunto de pruebas unitarias, obtenidas de módulos, paquetes y archivos
enumerados en la línea de comando.

trial tomará nombres de archivo o nombres de Python completamente calificados como argumentos. Por lo tanto
`trial myproject / foo.py ',` trial myproject.foo' y `trial
myproject.foo.SomeTestCase.test_method 'son todas formas válidas de invocar la prueba. Múltiples tales
También se aceptan argumentos, y su orden determinará el orden en el que
se ejecutan las pruebas correspondientes.

Después de ejecutar el conjunto de pruebas dado, el reportero de prueba predeterminado imprime un resumen de la prueba
correr. Consiste en la palabra "APROBADO" (si todas las pruebas se ejecutaron como se esperaba) o "NO APROBADO" (si alguna
prueba se comportó inesperadamente) seguido de un recuento de los diferentes tipos de resultados de prueba
encontrado. Los posibles tipos de resultados de las pruebas incluyen:

éxitos
Pruebas que aprobaron todas sus afirmaciones y se completaron sin error. Estos son
marcado como "APROBADO" en la salida de prueba normal.

fallas
Pruebas que fallaron en una afirmación, llamadas self.fail () o planteadas explícitamente
self.failureException por alguna razón. Estos están marcados como "FALLIDO" en la prueba normal.
salida.

errores Pruebas que generaron una excepción inesperada (incluido AssertionError), pruebas que
provocó que el método tearDown () generara una excepción, pruebas que se ejecutan durante más de
el intervalo de tiempo de espera, pruebas que hicieron que algo llamara twisted.python.log.err ()
sin llamar posteriormente a self.flushLoggedErrors (), pruebas que abandonan el reactor
en un estado sucio, etc. Estos están marcados como "ERROR" en la salida de prueba normal.

Tenga en cuenta que debido a que pueden producirse errores después de que regrese el método de prueba real, es
posible que una sola prueba se informe como un error y un fracaso, y por lo tanto
el número total de resultados de la prueba puede ser mayor que el número total de pruebas
ejecutado.

omite las pruebas que se omitieron, generalmente debido a dependencias faltantes. Estos están marcados
"SALTADO" en la salida de prueba normal.

errores esperados
Pruebas que fallaron, pero se esperaba que fallaran, generalmente porque la prueba es para un
característica que aún no se ha implementado. Estos están marcados como "TODO" en el formato normal.
salida de prueba.

éxitos inesperados
Pruebas que deberían haberse incluido en Fallos esperados, excepto para algunos
razón por la que la prueba tuvo éxito. Estos están marcados como "¡¿ÉXITO!?!" en la salida de prueba normal.

OPCIONES

-j, --trabajos número
Establezca el número de trabajadores del proceso que se ejecutarán. Entra en conflicto con la depuración, exitfirst
y opciones de perfil.

-b, --depurar
Ejecute las pruebas en un depurador. Si ese depurador es 'pdb' (que es el predeterminado si
sin especificar), se cargará un `.pdbrc 'desde el directorio actual si existe.
También realiza depuración post-mortem en excepciones.

-B, --debug-stacktraces
Informe de seguimiento de pila de devolución de llamada y creación diferida.

--cobertura
Genere información de cobertura en el subdirectorio "cobertura" de la prueba temporal.
directorio ('_trial_temp' por defecto). Para cada módulo de Python tocado por el
ejecución de las pruebas dadas, se creará un archivo en el directorio de cobertura
nombrado por el nombre completo del módulo con el sufijo '.cover'. Por ejemplo,
debido a que el corredor de prueba de prueba está escrito en Python, el directorio de cobertura
casi siempre contienen un archivo llamado `twisted.trial.runner.cover '.

Cada archivo `.cover 'contiene una copia de la fuente Python del módulo en cuestión,
con un prefijo al principio de cada línea que contiene información de cobertura. Para
líneas que no son ejecutables (líneas en blanco, comentarios, etc.) el prefijo está en blanco.
Para las líneas ejecutables que se ejecutaron en el transcurso del conjunto de pruebas, el prefijo es un
número que indica el número de veces que se ejecutó esa línea. La cadena `>>>>>> '
prefija líneas ejecutables que no se ejecutaron en el transcurso de la suite de pruebas.

Tenga en cuenta que esta funcionalidad usa la función sys.settrace () de Python, por lo que prueba que
llamar sys.settrace () es probable que rompa la funcionalidad de cobertura de prueba.

--depurador
Especifica el depurador que se utilizará cuando se pase la opción --debug. El argumento
debe ser el nombre completo de un objeto que implementa la misma interfaz
como el `pdb 'de la biblioteca estándar.

--disablegc
Desactive el recolector de basura durante la ejecución de la prueba. Como cada prueba es
ejecutar, prueba guarda los objetos TestResult, lo que significa que la basura de Python
recolector tiene más objetos que no son basura para atravesar, lo que hace que cada basura-
la recolección se ejecuta un poco más lento. Deshabilitar la recolección de basura por completo hará
algunos conjuntos de pruebas se completan más rápido (contraste --force-gc, a continuación), a costa de
aumentando (posiblemente en gran medida) el consumo de memoria. Esta opción también hace pruebas
un poco más determinista, lo que podría ayudar a depurar en circunstancias extremas.

-e, - terrores
Imprima trazas en la salida estándar tan pronto como ocurran.

--fuerza-gc
Ejecute gc.collect () antes y después de cada caso de prueba. Esto se puede utilizar para aislar
errores que ocurren cuando se recolectan objetos. Esta opción sería la predeterminada,
excepto que hace que las pruebas se ejecuten unas diez veces más lento.

-h, --ayuda
Imprima un mensaje de uso en la salida estándar y luego salga.

- orden de ayuda
Imprima una lista de posibles pedidos en los que se pueden ejecutar los métodos de prueba de TestCase, luego
Salida. Los pedidos se pueden utilizar con la opción --order que se describe a continuación.

--reporteros de ayuda
Imprima una lista de reporteros válidos en la salida estándar, luego salga. Los reporteros pueden ser
seleccionado con la opción --reporter que se describe a continuación.

--reactores de ayuda
Imprima una lista de posibles reactores a la salida estándar, luego salga. No todos en la lista
Los reactores están disponibles en todas las plataformas. Los reactores se pueden seleccionar con el
- opción de reactor descrita a continuación.

-l, --archivo de registro archivo de registro
Dirija el registro a un archivo diferente. El archivo predeterminado es `test.log '. archivo de registro is
relativo a _trial_temp.

-n, - corrida en seco
Realice todas las pruebas y hágalas pasar sin correr.

-N, --no recurrente
De forma predeterminada, la prueba se repite a través de paquetes para encontrar cada módulo dentro de cada
subpaquete. A menos que, es decir, especifique esta opción.

--nopm No salte automáticamente al depurador para el análisis post mortem de excepciones.
Solo se puede utilizar junto con --debug.

--pedido solicite
Especifique en qué orden ejecutar los métodos de prueba individuales dentro de los TestCases dados.
De forma predeterminada, se ejecutan alfabéticamente. Consulte --help-order para obtener una lista de otros
valores.

--perfil
Ejecute pruebas con el generador de perfiles de Python.

-r, --reactor reactor
Elija qué reactor usar. Consulte --help-reactors para obtener una lista.

- límite de recursividad límitar
Establece el límite de recursividad de Python. Consulte sys.setrecursionlimit ().

--reportero molécula indicadora
Seleccione el reportero que se utilizará para la salida de la prueba. Utilice la opción --help-reporters para
ver una lista de reporteros válidos.

-x, --salir primero
Detenga la ejecución de la prueba después de la primera prueba que no tuvo éxito. Esto incluye
fracasos, errores o éxitos inesperados. No funcionará con la opción --jobs
actualmente.

--arrojar Imprime un registro increíblemente detallado de todo lo que sucede. Útil al depurar
congela o bloquea en código complejo.

--formato tb formato
Formato para mostrar los rastreos con. Los valores aceptables son "predeterminado", "breve" y
'detallado'. 'brief' produce trazas que funcionan muy bien con GUD de Emacs.

--directorio temporal directorio
ADVERTENCIA: No use esta opción a menos que sepa lo que está haciendo. Por defecto,
trial crea un directorio llamado _trial_temp bajo el directorio de trabajo actual.
Cuando se ejecuta la prueba, primero elimina este directorio, luego lo crea, luego cambia
en el directorio para ejecutar las pruebas. El archivo de registro y los archivos de cobertura se almacenan
aquí. Utilice esta opción si desea ejecutar la prueba en un directorio que no sea
_trial_temp. Tenga cuidado, el juicio será borrar el directorio antes de volver a crearlo.

--módulo de prueba nombre de archivo
Pida a juicio que investigue nombre de archivo y ejecutar cualquier prueba especificada usando el estilo Emacs
variable de búfer `test-case-name '.

- advertencias de impurezas
A partir de Twisted 8.0, la prueba informará un error si el reactor se deja sucio en el
final de la prueba. Esta opción se proporciona para ayudar en la migración de Twisted 2.5 a
Twisted 8.0 y posteriores. Habilitar esta opción convertirá los errores en advertencias.

-u, --hasta el fracaso
Siga repitiendo las pruebas hasta que una de ellas presente un error o una falla. Este es
particularmente útil para reproducir fallas intermitentes.

--versión
Imprime el número de versión Twisted y sale.

--sin módulo nombres de módulo
Simule la falta de la lista especificada de módulos separados por comas. Esto lo hace
parece que los módulos no están presentes en el sistema, lo que hace que las pruebas
comportamiento para esa configuración.

-z, --aleatorio dispersores
Ejecute las pruebas en orden aleatorio utilizando la semilla especificada. No pase esta opción si
también estás pasando --orden.

Utilice la prueba en línea utilizando los servicios de onworks.net