Pruebas de unidad de escritura en Django/Python

Question

No he utilizado pruebas de unidad antes de una breve introducción en un curso de Uni. Actualmente estoy escribiendo una aplicación y me gustaría enseñarme a mí mismo TDD en el proceso. El problema es que no tengo idea de qué probar o cómo.

Estoy escribiendo una aplicación Django, y hasta ahora solo he creado los modelos (y he personalizado la aplicación de administración). Esta es la forma en que he escrito los esqueletos de mis pruebas hasta el momento:

class ModelTests(TestCase): 
    fixtures = ['initial_data.json',] 

    def setUp(self): 
     pass 

    def testSSA(self): 
     ssa = SSA.objects.create(name="sdfsdf", cost_center=1111, street_num=8, 
       street_name="dfsdfsf Street", suburb="sdfsdfsdf", 
       post_code=3333) 


    def testResident(self): 
     pass 

    def testSSA_Client(self): 
     pass 

tenía planeado escribir una función para probar cada modelo dentro de la clase ModelTests. ¿Es esta una buena forma de escribir pruebas? Además, ¿qué debería probar exactamente? ¿Que crear un modelo con todos los campos completados funciona? ¿Que un modelo medio completo falla? ¿Qué casos especiales se prueban (como null e is_required = False)? Confío en el ORM, que hasta donde tengo conocimiento está fuertemente probado, así que no debería necesitar probar todos los métodos, ¿o sí?

¿Qué debo probar para una aplicación web escrita en Django/Python? Algunos ejemplos serían agradables.

Answer 1

¿Es una función para probar cada modelo dentro de la clase ModelTests una buena forma de escribir pruebas?

Nº

¿Qué es exactamente debería estar probando para?

• Que la creación de un modelo con todos los campos completados funciona?

• ¿Qué modelo medio completo falla?

• ¿Qué casos especiales se prueban (como null y is_required = False)?

• He confiado en el ORM, que hasta donde yo sé, ha sido sometido a pruebas, por lo que no debería tener que probar todos los métodos, ¿o sí?

No mucho de eso.

Puede probar las reglas de validación, pero eso no tiene sentido hasta que haya definido algunos objetos Form. Luego tiene algo que probar: ¿impone la forma todas las reglas? Necesitará al menos una clase TestCase para cada formulario. Una función será un escenario: diferentes combinaciones de entradas permitidas o no permitidas.

Para cada clase de modelo, necesitará al menos una definición de clase TestCase. TestCases es barato, define muchos de ellos.

Su modelo representa las definiciones de "entidad comercial". Sus modelos tendrán métodos que implementen reglas comerciales. Sus métodos harán cosas como resumir, filtrar, calcular, agregar, reducir, todo tipo de cosas. Tendrá funciones para cada una de estas características de una clase modelo.

No estás probando Django. Está probando cómo las reglas de su negocio realmente funcionan en Django.

Más adelante, cuando tenga más cosas en su aplicación (formularios, vistas, URL, etc.), querrá usar el cliente de prueba unitario Django para ejercitar cada método para cada url. De nuevo, un TestCase por

Answer 2

No estoy exactamente seguro de los detalles de lo que está tratando de probar aquí, necesitaría más fragmentos de código para esto, pero puedo darle algunos consejos generales.

Primero, lea el capítulo de pruebas de unidades de "Inmersión en Python" (es gratis en línea! http://diveintopython3.ep.io/unit-testing.html), es una gran explicación de pruebas unitarias en general, qué necesita hacer y por qué.

En segundo lugar, en lo que respecta a TDD, es una práctica valiosa, pero tenga cuidado de no depender demasiado de ella, ya que he encontrado que puede dar lugar a una sobre especificación de software y más software que no se puede volver a -desarrollado y adaptado a nuevas tareas. Esta es solo mi experiencia, mente. Además, siempre que no lo uses dogmáticamente, TDD es valioso.

En tercer lugar, me parece que el mejor consejo para su situación específica es esforzarse por probar su lógica, pero no la lógica de los marcos que usted depende de. Eso significa que a menudo probar modelos medio completos, etc. puede no ser apropiado, ya que esa no es tu lógica, sino la de Django, y por lo tanto ya debería probarse. Sería más valioso probar algunos casos esperados, ejemplos que espera, excepciones que espera, etc. para asegurarse de que la especificación de su modelo sea correcta y luego pasar a la lógica más sustancial de su aplicación.

Answer 3

Probablemente ya haya leído Pruebas Django Applications.

Comience probando los casos de uso normal de su aplicación, creando un nuevo usuario, agregando una entrada de blog, etc. Simplemente sus operaciones CRUD típicas primero, luego muévase a las cajas de borde. Básicamente, usted genera confianza en su aplicación de que cualquier cosa que modifique más adelante no romperá la forma en que espero que se comporte la aplicación.

Simula solicitudes GET/POST en tus URL y observa las respuestas (encabezados, códigos de estado y contenido). ¿Tu aplicación mostró la vista correcta? Usando la plantilla correcta? En las secciones donde su aplicación arroja excepciones, intente activarlas (por ejemplo, vea/edite un registro inexistente para generar ObjectDoesNotExist).

Por lo general, vale la pena poner en un sistema de seguimiento (por ejemplo, Trac), por lo que puede agregar una nueva prueba para cada defecto registrado.