python - test - pruebas unitarias django

Escritura de casos de prueba para modelos django

Question

A la mitad de mi proyecto actual, después de sufrir el dolor de pasar innumerables minutos en la depuración, he decidido adoptar TDD. Para comenzar, estoy planeando escribir un conjunto de pruebas unitarias para cada modelo existente. Pero para los modelos que solo tienen atributos definidos (es decir, sin métodos / propiedades adicionales) no estoy seguro de qué es lo que necesito probar ni cómo.

class Product(models.Model):
name = models.CharField(max_length=50)
description = models.TextField(default='''', blank=True)
retails = models.ManyToManyField(Retail, verbose_name=''Retail stores that carry the product'')
manufacturer = models.ForeignKey(Manufacturer, related_name=''products'')
date_created = models.DateTimeField(auto_now_add=True)
date_modified = models.DateTimeField(auto_now=True)

Usando Producto como ejemplo, ¿cuáles son las cosas que deberían cubrir las pruebas unitarias? ¿Y cómo deberían cubrirse ForeignKey y ManyToManyField ?

Answer 1

Este fue un artículo que encontré útil: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/ . Aquí hay un buen resumen de qué probar:

Otro revés común para los desarrolladores / diseñadores nuevos en las pruebas es la pregunta de ''¿qué debería (o no debería) probar?'' Si bien no existen reglas estrictas que se apliquen con precisión en todas partes, existen algunas pautas generales que puedo ofrecer al tomar la decisión:

• Si el código en cuestión es una función / biblioteca incorporada de Python, no lo pruebe. Ejemplos como la biblioteca de fecha y hora.

• Si el código en cuestión está integrado en Django, no lo pruebe. Ejemplos como los campos en un Modelo o prueba cómo la plantilla incorporada. Nodo representa las etiquetas incluidas.

• Si su modelo tiene métodos personalizados, debe probar eso, generalmente con pruebas unitarias.

• Lo mismo ocurre con vistas personalizadas, formularios, etiquetas de plantilla, procesadores de contexto, middleware, comandos de gestión, etc. Si implementó la lógica comercial, debe probar sus aspectos del código.

Entonces, para su ejemplo, realmente no habría nada para probar hasta que escriba algunas funciones personalizadas.
En mi opinión, probar los enlaces ForeignKey y ManyToManyField entraría en la segunda categoría (código integrado en Django), por lo que no los probaría, ya que realmente se está probando si Django funciona correctamente o no. Si tiene un método que crea una instancia de su producto, incluidas relaciones extranjeras y M2M, puede verificar que se hayan creado los datos, que se estaría probando su método personalizado, no la funcionalidad de Django.

Utilizando el paradigma TDD, las pruebas se crean para verificar la lógica comercial y los requisitos de diseño.