python - pruebas - Cobertura de prueba de Django vs cobertura de código

crear pruebas unitarias django

Question

He instalado y configurado exitosamente django-nose con coverage

El problema es que si ejecuto la cobertura para el ./manage.py shell y salgo de ese shell, me muestra el 37% de la cobertura del código. Entiendo completamente que el código ejecutado no significa código probado . Mi única pregunta es: ¿y ahora qué?

Lo que estoy imaginando es poder importar todos los módulos de Python y "establecerse" antes de ejecutar cualquier prueba y comunicarse directamente con la coverage diciendo "Ok, comience a contar el código alcanzado aquí".

Lo ideal sería que esto se hiciera por la nose esencialmente restableciendo las líneas de código "tocadas" justo antes de ejecutar cada conjunto de pruebas.

No sé por dónde empezar a buscar / desarrollar. He buscado en línea y no he encontrado nada fructífero. Cualquier ayuda / guía sería muy apreciada.

PD

Intenté ejecutar algo como esto:

DJANGO_SETTINGS_MODULE=app.settings_dev coverage run app/tests/gme_test.py

Y funcionó (mostró una cobertura del 1%) pero no puedo averiguar cómo hacerlo para toda la aplicación

Edición : Aquí está mi configuración de cobertura:

[run]
source = .
branch = False
timid = True
[report]
show_missing = False
include = *.py
omit =
    tests.py
    *_test.py
    *_tests.py
    */site-packages/*
    */migrations/*
[html]
title = Code Coverage
directory = local_coverage_report

Answer 1

El "Ok, empieza a contar el código alcanzado aquí". Se puede hacer a través de la API del módulo de cobertura. Usted puede ver esto a través de la cáscara. Robó directamente desde http://nedbatchelder.com/code/coverage/api.html :

import coverage

cov = coverage.coverage()
cov.start()

# .. call your code ..

cov.stop()
cov.save()

cov.html_report()

Puede hacer que su propio corredor de prueba haga esto exactamente para que se ajuste a sus necesidades (algunos considerarían que la cobertura realizada desde cualquier prueba de unidad está bien, y otros solo aceptarían la cobertura de una unidad causada por la prueba de unidad para esa unidad). .)

Answer 2

Estoy un poco confundido por lo que estás tratando de lograr aquí.

Las pruebas en Django se tratan muy bien aquí: https://docs.djangoproject.com/en/dev/topics/testing/overview/

Escribes pruebas en tu aplicación como test.py: no veo la necesidad de la nariz, ya que la forma estándar de django es bastante simple.

Luego ejecútelos como coverage run ./manage.py test main - donde ''principal'' es su aplicación

Especifique los archivos de origen para su código como se documenta aquí: http://nedbatchelder.com/code/coverage/cmd.html para que solo se cuente su código

Ej. cobertura ejecutar --source = main ./manage.py test main

Aún obtendrá un cierto porcentaje marcado como cubierto con la prueba simple que se proporciona como ejemplo. Esto se debe a que partes de su código se ejecutan para iniciar el servidor, por ejemplo, definiciones en módulos, etc.

Answer 3

Tuve el mismo problema. Ahorré algo de tiempo al crear un archivo .coveragerc que especificaba opciones similares a las descritas en la respuesta con recompensa.

Ahora ejecutando ''cover run manage.py test'' y luego ''cover report -m'' me mostrará el informe de cobertura y las líneas que no están cubiertas.

(Consulte aquí para obtener detalles sobre el archivo .coveragerc: http://nedbatchelder.com/code/coverage/config.html )

Answer 4

ya que usa django-nose, tiene dos opciones sobre cómo ejecutar la cobertura. El primero ya fue señalado por DaveB:

coverage run ./manage.py test myapp

Lo anterior realmente ejecuta la cobertura que luego supervisa todo el código ejecutado por el comando de prueba.

Pero luego, también hay un complemento de cobertura de nariz incluido de forma predeterminada en el paquete django-nose ( http://nose.readthedocs.org/en/latest/plugins/cover.html ). Puedes usarlo así:

./manage.py test myapp --with-coverage

(También hay algunas opciones adicionales como los módulos que deben cubrirse, ya sea para incluir un informe html o no, etc. Todos estos están documentados en el enlace anterior, también puede escribir ./manage.py test --help para obtener información rápida ).

Ejecutar el complemento de cobertura de la nariz dará como resultado que la cobertura se ejecute después de que se ejecute el código de arranque de django y, por lo tanto, el código correspondiente no se informará como cubierto.

La mayoría del código que se ve como cubierto cuando se ejecuta la cobertura de manera original, son declaraciones de importación, definiciones de clase, miembros de la clase, etc. A medida que Python los evalúa durante el tiempo de importación, la cobertura los marcará como cubiertos. Sin embargo, ejecutar el complemento de la nariz no informará el código de arranque como cubierto, ya que el corredor de prueba se inicia después de que se carga el entorno django. Por supuesto, un efecto secundario de esto es que nunca puede lograr una cobertura del 100% (... o cerrar :)) ya que sus declaraciones de alcance global nunca serán cubiertas.

Después de cambiar de un lado a otro y jugar con las opciones de cobertura, ahora he terminado usando una cobertura como esta:

coverage run --source=myapp,anotherapp ---omit=*/migrations/* ./manage.py test

de modo que a) la cobertura informará las declaraciones de importación, las definiciones de los miembros de la clase, etc. como cubiertas (lo que en realidad es la verdad, este código se importó e interpretó con éxito) yb) solo cubrirá mi código y no el código django, o cualquier otro tercero Aplicación de fiesta que utilizo; el porcentaje de cobertura reflejará qué tan bien está cubierto mi proyecto. ¡Espero que esto ayude!