Curso Python. Volumen XIX: Framework Django. Parte XIII

Bienvenidos un día más al curso de Python, en este capítulo vamos a crear nuestra primera prueba automática que implementaremos en la aplicación que estamos creando con el framework Django. Estas pruebas automáticas nos ayudarán a asegurarnos que nuestra aplicación funciona de manera correcta. Así que pongámonos manos a la obra.

Escribiendo nuestra primera prueba:

Buscando un error

Cuando hemos estado construyendo la aplicación de las encuestas, dejamos un error de manera intencionada, ese error se encuentra en el método “Pregunta.was_published_recently()” ya que nos devuelve “True” si una Pregunta fue publicada el día anterior (lo que es correcto), pero también si el campo “fecha_publi” es en el futuro (lo que es incorrecto).

Esto lo podemos comprobar desde el “Administrador”. Para ellos creamos una pregunta cuya fecha es en el futuro y veremos que el listado de preguntas nos dice que fue publicada recientemente. También podemos comprobarlo usando la consola Python:

>>>import datetime 
>>>from django.utils import timezone
>>>from polls.models import Pregunta
>>># create a Question instance with pub_date 30 days in the future
>>>future_question = Pregunta(fecha_publi=timezone.now() + datetime.timedelta(days=30))
>>># was it published recently?
>>>future_question.was_published_recently()
True

Dado que las preguntas que se publicarán en el futuro no son ‘recientes’, esto es incorrecto y tenemos que corregirlo.

Creamos un test que exponga el bug

Lo que acabamos de hacer en la consola de Python para verificar el problema es exactamente lo que podemos hacer en una prueba automática. Así que vamos a crear una prueba que haga lo expuesto anteriormente.

El lugar donde se crean las pruebas es en el archivo tests.py, el programa que se encarga de ejecutar las pruebas busca los archivos que empiecen por test. Vamos a agregar el siguiente código en el archivo tests.py en la aplicación polls:

polls/tests.py 

import datetime
from django.utils import timezone
from django.test import TestCase
from .models import Pregunta

class QuestionMethodTests(TestCase):
def test_was_published_recently_with_future_question(self):
"""
was_published_recently() debera devolver False si la pregunta tiene como fecha_publi una fecha superior a la actual
fecha_publi es una fecha futura.
"""
time = timezone.now() + datetime.timedelta(days=30)
future_question = Pregunta(fecha_publi=time)
self.assertEqual(future_question.was_published_recently(), False)

Lo que hemos realizado en este código es crear una subclase de “django.test.TestCase” con un método que crea una instancia de “Pregunta” con un valor de fecha_publi en el futuro. Luego comprobamos la salida de “was_published_recently()”, la cual debería ser False.

Ejecutar las pruebas automáticas

Para la ejecución de las pruebas automáticas, nos podemos dirigir a la consola de Windows y lanzar la ejecución de la prueba:

$ Python manage.py test polls

El resultado de la ejecución anterior será algo parecido a:

Creating test database for alias 'default'... 
F
====================================================
FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionMethodTests)
----------------------------------------------------
Traceback (most recent call last):
File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question
self.assertEqual(future_question.was_published_recently(), False)
AssertionError: True != False
-----------------------------------------------------
Ran 1 test in 0.001s
FAILED (failures=1)
Destroying test database for alias 'default'...

Vamos a explicar que es lo que ha ocurrido en la prueba.

“Python manage.py test polls” buscó pruebas en la aplicación polls, encontró una subclase de django.test.TestCase, también creó una base de datos especial para las pruebas. Después buscó los métodos de pruebas que son aquellos cuyo nombre comienza con test.

Una vez terminado eso creó una instancia de “Pregunta” cuyo valor para el campo “fecah_publi” es 30 días en el futuro dentro del método “test_was_published_recently_with_future_question” y a través del método assertEqual(), descubrió que “was_published_recently()” nos devuelve “True”, a pesar de que queríamos que devolviera “False”.

La ejecución nos informa que la prueba realizada falló e incluso nos indica la línea en la que se ha producido el fallo.

Arreglando el error

Ahora ya sabemos cuál es el problema: “Pregunta.was_published_recently()” debería devolver “False” si “fecha_publi” tiene un valor en el futuro. Nos dirigiremos al método correspondiente dentro de “models.py”, para corregirlo y hacer que sólo devuelva “True” si además la fecha es en el pasado:

polls/models.py 

def was_published_recently(self):
now = timezone.now()
return now - datetime.timedelta(days=1) <= self.fecha_publi <= now

Una vez corregido, volveremos a ejecutar la prueba:

Creating test database for alias 'default'... 
.
----------------------------------------------------
Ran 1 test in 0.001s
OK
Destroying test database for alias 'default'...

Como habréis podido comprobar lo que hemos hecho es que después de identificar el error, hemos escrito una prueba en la que lo que se expone y se corrige es el problema en el código para que nuestra prueba no salga fallida.

Es verdad que nuestra aplicación podrá contener más errores, pero con esta práctica lo que vamos a evitar es que volvamos a cometer errores ya corregidos. Ya que sólo con ejecutar las pruebas sabremos si todo sigue funcionando correctamente. Por lo que podemos considerar que esta porción de código de nuestra aplicación estará funcionando de manera correcta en nuestra aplicación.

Pruebas más exhaustivas.

Ya que estamos con el método “was_published_recently()”, vamos a aprovechar el momento  y vamos a mejorar la prueba ya que no queremos haber creado un error nuevo después de haber corregido uno. Para ello vamos a agregar dos métodos más a la misma clase, para probar el comportamiento del método de forma más exhaustiva:

polls/tests.py 

def test_was_published_recently_with_old_question(self):
"""
was_published_recently() should return False for questions whose
pub_date is older than 1 day.
"""
time = timezone.now() - datetime.timedelta(days=30)
old_question = Pregunta(fecha_publi=time)
self.assertEqual(old_question.was_published_recently(), False)

def test_was_published_recently_with_recent_question(self):
"""
was_published_recently() should return True for questions whose
pub_date is within the last day.
"""
time = timezone.now() - datetime.timedelta(hours=1)
recent_question = Pregunta(fecha_publi=time)
self.assertEqual(recent_question.was_published_recently(), True)

Después de introducir este código, comprobaréis que ahora tenemos tres pruebas que confirman que “Pregunta.was_published_recently()” devuelve valores correctos para preguntas pasadas, recientes y futuras.

De nuevo, polls es una aplicación simple, pero sin importar lo complejo que pueda crecer en el futuro o la interacción que pueda tener con otro código, tenemos alguna garantía de que el método para el cual hemos escrito tests se comportará de la manera esperada.

Probando una vista

Nuestra aplicación de encuestas siempre va a publicar una pregunta, incluso cuanto el campo “fecha_publi” de la pregunta, es una fecha en el futuro. Éste es un aspecto de la vista que deberíamos mejorar. Tener una “fecha_publi” en el futuro debería significar que la pregunta se publica en ese momento, pero permanece invisible hasta entonces.

Una prueba para una vista

Cuando arreglamos el error de arriba, escribimos una prueba primero y luego el código que lo arreglaba. De hecho fue un ejemplo simple de “test-driven development”, pero no importa en realidad el orden en que lo hicimos.

En nuestra primera prueba nos concentramos en el comportamiento interno del código. Para esta prueba, queremos comprobar el comportamiento como lo experimentaría un usuario mediante el navegador web. Antes de intentar arreglar cualquier cosa, veamos las herramientas que tenemos a nuestra disposición.

El cliente para pruebas de Django

“Django” provee un cliente para pruebas. “Client” sirve para simular la interacción del usuario con el código a nivel de vista. Podemos usarlo en tests.py o incluso en la consola de Python. Empezaremos de nuevo con la consola de Python, donde necesitamos hacer un par de cosas que no serán necesarias en tests.py. La primera es crear el ambiente de pruebas en la consola de Python:

>>> from django.test.utils import setup_test_environment 
>>> setup_test_environment()

“setup_test_environment()” instala un renderizador de plantillas que nos permitirá examinar algunos atributos adicionales en las respuestas, tales como “response.context”, que de otra forma no estarían disponibles. Fijaos que este método no configura una base de datos para pruebas, entonces lo que ejecutemos a continuación, va a ser contra la base de datos existente y la salida podría diferir dependiendo de las preguntas que hayamos creado.

A continuación necesitamos importar la clase del cliente para pruebas (luego en tests.py vamos a usar la clase “django.test.TestCase”, que viene con su propio cliente, así que este paso no será necesario):

>>>from django.test import Client 
>>># create an instance of the client for our use
>>>client = Client()

Una vez realizado todo esto, ya podemos pedirle al cliente que haga trabajo por nosotros:

>>># get a response from '/' 
>>>response = client.get('/')
>>># we should expect a 404 from that address
>>>response.status_code
404
>>># on the other hand we should expect to find something at '/polls/'
>>># we'll use 'reverse()' rather than a hardcoded URL
>>>from django.core.urlresolvers import reverse
>>>response = client.get(reverse('polls:index'))
>>>response.status_code
200
>>>response.content
<span class="go">'\n\n\n

No polls are available.

\n\n
</span>>>># note - you might get unexpected results if your ``TIME_ZONE``
>>># in ``settings.py`` is not correct. If you need to change it,
>>># you will also need to restart your shell session
>>>from polls.models import Pregunta
>>>from django.utils import timezone
>>># create a Pregunta and save it
>>>q = Pregunta(texto_pregunta="Who is your favorite Beatle?", fecha_publi=timezone.now())
>>>q.save()
>>># check the response once again
>>>response = client.get('/polls/')
>>>response.content
'\n\n\n    <ul>\n    \n        <li><a href="/polls/1/">Who is your favorite Beatle?</a></li>\n    \n    </ul>\n\n'
>>> # If the following doesn't work, you probably omitted the call to
>>> # setup_test_environment() described above
>>>response.context['latest_question_list']
[<Question: Who is your favorite Beatle?>]

Esto es todo por hoy, os invitamos como siempre a que sigáis explorando este framework y probándolo. Seguir ejecutando más pruebas a vuestra vista. En el próximo capítulo seguiremos trabajando con las pruebas automáticas para las vistas.

Y para todos los que se acaban de incorporar indicarles que tenemos un índice con todos los capítulos del curso, ya que nunca es tarde para empezar.



Via: www.redeszone.net
Curso Python. Volumen XIX: Framework Django. Parte XIII Curso Python. Volumen XIX: Framework Django. Parte XIII Reviewed by Zion3R on 13:20 Rating: 5