Este tutorial comienza donde quedó el Tutorial 4. Hemos creado una aplicación Web de encuestas y ahora vamos a crear algunas pruebas automatizadas para ella.
\nLas pruebas son simples rutinas que comprueban el funcionamiento de su código.
\nLas pruebas se ejecutan en diferentes niveles. Algunas pruebas se pueden aplicar a un pequeño detalle (¿Un método de modelo particular retorna valores como se espera?) mientras que otras examinan el total funcionamiento del software (¿Una secuencia de entradas de usuarios en el sitio produce el resultado deseado?). No se diferencia del tipo de pruebas que ejecutó anteriormente en el Tutorial 2 utilizando el comando shell para examinar el comportamiento de un método, o ejecutar la aplicación e ingresar datos para comprobar cómo se comporta.
Lo que es diferente en las pruebas automatizadas es que el trabajo de pruebas por usted lo hace el sistema. Usted crea un conjunto de pruebas una vez, después, a medida que modifica su aplicación, puede comprobar que el código todavía funciona como originalmente lo concibió, sin necesidad de pruebas manuales engorrosas.
\nEntonces, ¿por qué crear pruebas y por qué ahora?
\nUsted podría pensar que ya con aprender Python y Django tiene bastante con qué ocuparse, y que tener que aprender y hacer aún más cosas podría ser abrumador y hasta innecesario. Después de todo, nuestra aplicación encuestas está funcionando ahora bastante bien, tomarse la molestia de crear pruebas automatizadas no va a hacer que funcione mejor. Si crear la aplicación encuestas es el último fragmento de programa de Django que hará, entonces es verdad, usted no necesita saber cómo crear pruebas automatizadas. Sin embargo, si ese no es el caso, ahora es un momento excelente para aprender.
\nHasta cierto punto, “comprobar de que parece funcionar” será una prueba satisfactoria. En una aplicación más sofisticada, es posible que tenga decenas de interacciones complejas entre los componentes.
\nUna cambio en cualquiera de esos componentes podría tener consecuencias inesperadas en el comportamiento de la aplicación. Comprobar que todavía “parece funcionar” podría significar pasar por la funcionalidad de su código con veinte variaciones diferentes de sus datos de prueba solo para asegurarse de que no ha roto algo; lo cual no es un buen uso de su tiempo.
\nEso es especialmente cierto cuando las pruebas automatizadas pueden hacer esto por usted en cuestión de segundos. Si algo salió mal, las pruebas también ayudarán a identificar el código que está causando el comportamiento inesperado.
\nA veces puede parecer un fastidio apartarse de su trabajo creativo y productivo de programación para afrontar la obligación poca atractiva y aburrida de escribir pruebas, particularmente cuando sabe que su código funciona de forma adecuada.
\nSin embargo, la tarea de escribir pruebas es mucho más gratificante que pasar horas probando su aplicación de forma manual o intentando identificar la causa de un problema recién introducido.
\nEs un error pensar en las pruebas sólo como un aspecto negativo del desarrollo.
\nSin las pruebas, el propósito o el comportamiento previsto de una aplicación podría ser bastante incomprensible. Aún cuando es su propio código, usted a veces se encontrará buscando en él tratando de averiguar qué es exactamente lo que hace.
\nLas pruebas cambian eso, ellas iluminan su código desde adentro, y cuando algo sale mal, ellas se centran en la parte que salió mal; incluso si usted no se ha dado cuenta de que salió mal.
\nUsted puede haber creado una brillante pieza de software, pero encontrará que muchos otros desarrolladores simplemente se negarán a verla porque carece de pruebas; sin pruebas, no van a confiar en ella. Jacob Kaplan-Moss, uno de los desarrolladores originales de Django, dice «El código sin pruebas es defectuoso por diseño.»
\nQue otros desarrolladores quieran ver pruebas en su software antes de que se lo tomen en serio es una razón más para que usted comience a escribir las pruebas.
\nLos puntos anteriores están escritos desde el punto de vista de un único desarrollador que mantiene una aplicación. Las aplicaciones complejas serán mantenidas por equipos. Las pruebas garantizan que los colegas no rompan inadvertidamente su código (y que usted no rompa el de ellos sin saber). Si quiere ganarse la vida como un programador de Django, ¡Usted debe ser bueno escribiendo pruebas!
\nHay muchas maneras de abordar la escritura de pruebas.
\nAlgunos programadores siguen una disciplina llamada «desarrollo basado en pruebas»; ellos efectivamente escriben las pruebas antes de escribir el código. Esto puede parecer ir contra el sentido común, pero en realidad es similar a lo que la mayoría de la gente a menudo hará de todos modos: describen un problema, a continuación, crean un código para resolverlo. El desarrollo basado en pruebas simplemente formaliza el problema en un caso de prueba Python.
\nLa mayoría de las veces, un principiante en pruebas va a crear código y luego decidirá que este debe tener algunas pruebas. Tal vez hubiera sido mejor escribir algunas pruebas antes, pero nunca es demasiado tarde para empezar.
\nA veces es difícil saber por dónde empezar con la escritura de pruebas. Si usted ha escrito varias miles de líneas de Python, elegir algo para probar podría no ser fácil. En tal caso, es provechoso escribir su primera prueba la próxima vez que realice una modificación, ya sea cuando agregue una nueva funcionalidad o solucione un error.
\nAsí que vamos a hacer eso de inmediato.
\nAfortunadamente, hay un pequeño bug en la aplicación polls para que lo solucionemos de inmediato: el método Question.was_published_recently() retorna True si la Question fue publicada en el último día (que es correcto), pero también si el campo de pub_date de Question está en el futuro (que de hecho no lo está).
Confirm the bug by using the shell to check the method on a question\nwhose date lies in the future:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> import datetime\n>>> from django.utils import timezone\n>>> from polls.models import Question\n>>> # create a Question instance with pub_date 30 days in the future\n>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))\n>>> # was it published recently?\n>>> future_question.was_published_recently()\nTrue\nPuesto que las cosas en el futuro no son “recientes”, esto es claramente erróneo.
\nLo que acabamos de hacer en el comando shell para detectar el problema es exactamente lo que podemos hacer en una prueba automatizada, así que vamos a convertir eso en una prueba automatizada.
Un lugar convencional para las pruebas de una aplicación se encuentra en el archivo tests.py de la aplicación; el sistema de pruebas encontrará automáticamente las pruebas en cualquier archivo cuyo nombre comience con test.
Ponga lo siguiente en el archivo tests.py de la aplicación polls:
import datetime\n\nfrom django.test import TestCase\nfrom django.utils import timezone\n\nfrom .models import Question\n\n\nclass QuestionModelTests(TestCase):\n\n def test_was_published_recently_with_future_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is in the future.\n """\n time = timezone.now() + datetime.timedelta(days=30)\n future_question = Question(pub_date=time)\n self.assertIs(future_question.was_published_recently(), False)\nHere we have created a django.test.TestCase subclass with a method that\ncreates a Question instance with a pub_date in the future. We then check\nthe output of was_published_recently() - which ought to be False.
In the terminal, we can run our test:
\nLinux / macOS
$ python manage.py test polls\nWindows
...\\> py manage.py test polls\ny usted verá algo como:
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\nF\n======================================================================\nFAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question\n self.assertIs(future_question.was_published_recently(), False)\nAssertionError: True is not False\n\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nFAILED (failures=1)\nDestroying test database for alias 'default'...\nEsto es lo que ocurrió:
\nmanage.py test polls looked for tests in the polls application
encontró una subclase de la: clase: clase django.test.TestCase
creó una base de datos especial para las pruebas
buscó métodos de prueba; aquellos cuyos nombres comienzan con test
en test_was_published_recently_with_future_question creó una instancia Question cuyo campo de pub_date está 30 días en el futuro
… y utilizando el método assertIs() descubrió que was_published_recently() retorna True, aunque queríamos que retornara False
La prueba nos informa que prueba falló e incluso la línea en la que se produjo el error.
\nYa sabemos cuál es el problema: Question.was_published_recently() debe devolver False si su pub_date está en el futuro. Modifique el método models.py, de modo que este sólo retornará True si la fecha está también en el pasado:
def was_published_recently(self):\n now = timezone.now()\n return now - datetime.timedelta(days=1) <= self.pub_date <= now\ny ejecute la prueba de nuevo:
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\n.\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nOK\nDestroying test database for alias 'default'...\nDespués de identificar un bug, escribimos una prueba que lo expone y corregimos el bug en el código para que nuestra prueba pase.
\nMuchas otras cosas podrían salir mal con nuestra aplicación en el futuro, pero podemos estar seguros de que no vamos a reintroducir este bug por descuido porque simplemente ejecutar la prueba nos avisará inmediatamente. Podemos considerar que esta pequeña parte de la aplicación está asegurada para siempre.
\nYa que estamos aquí, podemos además precisar el método was_published_recently(); de hecho, sería verdaderamente vergonzoso si al corregir un bug hubiéramos introducido otro.
Agregue dos métodos de pruebas más a la misma clase, para probar el comportamiento del método de forma más completa:
\ndef test_was_published_recently_with_old_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is older than 1 day.\n """\n time = timezone.now() - datetime.timedelta(days=1, seconds=1)\n old_question = Question(pub_date=time)\n self.assertIs(old_question.was_published_recently(), False)\n\ndef test_was_published_recently_with_recent_question(self):\n """\n was_published_recently() returns True for questions whose pub_date\n is within the last day.\n """\n time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)\n recent_question = Question(pub_date=time)\n self.assertIs(recent_question.was_published_recently(), True)\nY ahora tenemos tres pruebas que confirman que Question.was_published_recently() retorna valores razonables para preguntas pasadas, recientes y futuras.
Una vez más, encuestas es una aplicación sencilla, pero por muy compleja que se vuelva en el futuro e independientemente de cualquier otro código con que interactúe, ahora tenemos alguna garantía de que el método para el cual hemos escrito las pruebas se comportará de la manera esperada.
La aplicación encuestas no discrimina en lo absoluto: publicará cualquier pregunta, incluyendo aquellas cuyo campo de pub_date esté en el futuro. Deberíamos actualizar esto. Establecer un pub_date en el futuro debería significar que la pregunta se publica en ese momento, pero que será invisible hasta entonces.
Cuando corregimos el bug anterior, escribimos primero la prueba y luego el código para corregirlo. De hecho ese fue un simple ejemplo del desarrollo basado en pruebas, pero en realidad no importa en qué orden hacemos el trabajo.
\nEn nuestra primera prueba, nos centramos detalladamente en el comportamiento interno del código. Para esta prueba, queremos comprobar su comportamiento como lo experimentaría un usuario a través de un navegador web.
\nAntes de tratar de corregir algo, echemos un vistazo a las herramientas a nuestra disposición.
\nDjango proporciona una prueba Client para simular un usuario interactúando con el código al nivel de la vista. Podemos utilizarlo en tests.py o incluso en el shell.
We will start again with the shell, where we need to do a couple of\nthings that won’t be necessary in tests.py. The first is to set up the test\nenvironment in the shell:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> from django.test.utils import setup_test_environment\n>>> setup_test_environment()\nsetup_test_environment() instala un procesador de plantillas que nos permite examinar algunos atributos adicionales sobre respuestas como response.context que de otra forma no estarían disponibles. Tenga en cuenta que este método no crea una base de datos de pruebas, por lo que lo siguiente se ejecutará contra la base de datos existente y la salida puede variar levemente dependiendo de cuáles preguntas usted ya creó. Puede obtener resultados inesperados si su TIME_ZONE en el archivo settings.py no es correcto. Si no recuerda haberlo configurado anteriormente, verifíquelo antes de continuar.
A continuación tenemos que importar la clase de cliente de prueba (más tarde en tests.py usaremos la clase django.test.TestCase que viene con su propio cliente, por lo que esto no será necesario):
>>> from django.test import Client\n>>> # create an instance of the client for our use\n>>> client = Client()\nCon eso listo, podemos pedirle al cliente que haga un trabajo para nosotros:
\n>>> # get a response from '/'\n>>> response = client.get('/')\nNot Found: /\n>>> # we should expect a 404 from that address; if you instead see an\n>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably\n>>> # omitted the setup_test_environment() call described earlier.\n>>> response.status_code\n404\n>>> # on the other hand we should expect to find something at '/polls/'\n>>> # we'll use 'reverse()' rather than a hardcoded URL\n>>> from django.urls import reverse\n>>> response = client.get(reverse('polls:index'))\n>>> response.status_code\n200\n>>> response.content\nb'\\n <ul>\\n \\n <li><a href="/polls/1/">What's up?</a></li>\\n \\n </ul>\\n\\n'\n>>> response.context['latest_question_list']\n<QuerySet [<Question: What's up?>]>\nLa lista de encuestas muestra las encuestas que aún no están publicadas (es decir, aquellas que tienen una pub_date en el futuro). Vamos a solucionar eso.
En el Tutorial 4 presentamos una vista basada en clases, basada en ListView:
class IndexView(generic.ListView):\n template_name = 'polls/index.html'\n context_object_name = 'latest_question_list'\n\n def get_queryset(self):\n """Return the last five published questions."""\n return Question.objects.order_by('-pub_date')[:5]\nTenemos que modificar el método get_queryset() y cambiarlo para que también compruebe la fecha comparándolo con timezone.now(). En primer lugar tenemos que añadir un import:
from django.utils import timezone\ny luego hay que modificar el método get_queryset como sigue:
def get_queryset(self):\n """\n Return the last five published questions (not including those set to be\n published in the future).\n """\n return Question.objects.filter(\n pub_date__lte=timezone.now()\n ).order_by('-pub_date')[:5]\nQuestion.objects.filter(pub_date__lte=timezone.now()) retorna un queryset que contiene Questions cuya pub_date es menor o igual a, es decir, anterior o igual a timezone.now.
Now you can satisfy yourself that this behaves as expected by firing up\nrunserver, loading the site in your browser, creating Questions with\ndates in the past and future, and checking that only those that have been\npublished are listed. You don’t want to have to do that every single time you\nmake any change that might affect this - so let’s also create a test, based on\nour shell session above.
Agregue lo siguiente a polls/tests.py:
from django.urls import reverse\ny vamos a crear una función de atajo para crear preguntas, así como una nueva clase de pruebas:
\ndef create_question(question_text, days):\n """\n Create a question with the given `question_text` and published the\n given number of `days` offset to now (negative for questions published\n in the past, positive for questions that have yet to be published).\n """\n time = timezone.now() + datetime.timedelta(days=days)\n return Question.objects.create(question_text=question_text, pub_date=time)\n\n\nclass QuestionIndexViewTests(TestCase):\n def test_no_questions(self):\n """\n If no questions exist, an appropriate message is displayed.\n """\n response = self.client.get(reverse('polls:index'))\n self.assertEqual(response.status_code, 200)\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_past_question(self):\n """\n Questions with a pub_date in the past are displayed on the\n index page.\n """\n create_question(question_text="Past question.", days=-30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question.>']\n )\n\n def test_future_question(self):\n """\n Questions with a pub_date in the future aren't displayed on\n the index page.\n """\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_future_question_and_past_question(self):\n """\n Even if both past and future questions exist, only past questions\n are displayed.\n """\n create_question(question_text="Past question.", days=-30)\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question.>']\n )\n\n def test_two_past_questions(self):\n """\n The questions index page may display multiple questions.\n """\n create_question(question_text="Past question 1.", days=-30)\n create_question(question_text="Past question 2.", days=-5)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question 2.>', '<Question: Past question 1.>']\n )\nVeamos algunas de estas más de cerca.
\nEn primer lugar es una función de atajo a las preguntas, create_question, para eliminar parte de la repetición del proceso de creación de preguntas.
test_no_questions no crea ninguna pregunta, pero comprueba el mensaje: «No hay encuestas disponibles.» y verifica que latest_question_list esté vacía. Tenga en cuenta que la clase django.test.TestCase ofrece algunos métodos de aserción adicionales. En estos ejemplos utilizamos :meth:~django.test.SimpleTestCase.assertContains()` y assertQuerysetEqual().
En test_past_question creamos una pregunta y verificamos que aparezca en la lista.
En test_future_question creamos una pregunta con una pub_date en el futuro. La base de datos se reinicia para cada método de prueba, por lo que la primera pregunta ya no está allí, de modo que de nuevo el índice no debería tener ninguna pregunta.
Y así sucesivamente. En efecto, estamos utilizando las pruebas para contar una historia del ingreso de datos en el sitio administrativo y experiencia de usuario en el sitio, y comprobar que los resultados esperados se publican en cada estado y para cada nuevo cambio en el estado del sistema.
\nDetailViewLink to this heading#Lo que tenemos funciona bien; sin embargo, a pesar de que las preguntas futuras no aparecen en el índice, los usuarios pueden todavía llegar a ellas si saben o adivinan la dirección URL correcta. Así que tenemos que agregar una restricción similar a la DetailView:
class DetailView(generic.DetailView):\n ...\n def get_queryset(self):\n """\n Excludes any questions that aren't published yet.\n """\n return Question.objects.filter(pub_date__lte=timezone.now())\nY por supuesto, vamos a agregar algunas pruebas para comprobar que una Question cuya pub_date que está en el pasado se puede mostrar y que una con una pub_date en el futuro no se pueda:
class QuestionDetailViewTests(TestCase):\n def test_future_question(self):\n """\n The detail view of a question with a pub_date in the future\n returns a 404 not found.\n """\n future_question = create_question(question_text='Future question.', days=5)\n url = reverse('polls:detail', args=(future_question.id,))\n response = self.client.get(url)\n self.assertEqual(response.status_code, 404)\n\n def test_past_question(self):\n """\n The detail view of a question with a pub_date in the past\n displays the question's text.\n """\n past_question = create_question(question_text='Past Question.', days=-5)\n url = reverse('polls:detail', args=(past_question.id,))\n response = self.client.get(url)\n self.assertContains(response, past_question.question_text)\nDebemos agregar un método get_queryset similar a ResultsView y crear una nueva clase de pruebas para esa vista. Va a ser muy similar a lo que acabamos de crear; de hecho, habrá mucha repetición.
También podríamos mejorar nuestra aplicación de otras maneras, agregando pruebas a lo largo del camino. Por ejemplo, es una tontería que se puedan publicar Questions en el sitio que no tienen Choices. Por lo tanto, nuestras vistas podrían comprobar esto y excluir dichas Questions. Nuestras pruebas crearían una Question sin Choices y luego probarían que no está publicada, así como crearían una Question similar con Choices y probarían que está publicada.
Quizás se les debería permitir a los usuarios registrados en el sitio administrativo ver las Questions que no han sido publicadas, pero no a los visitantes ordinarios. Una vez más: lo que se tenga que agregar al software para lograr esto debería ir acompañado de una prueba, ya sea que escriba la prueba primero y luego haga que el código pase la prueba, o primero solucione la lógica en el código y luego escriba una prueba para probarlo.
En un momento dado usted está obligado a examinar sus pruebas y a preguntarse si su código sufre de exceso de pruebas, lo que nos lleva a:
\nPodría parecer que nuestras pruebas están creciendo fuera de control. A este paso pronto habrá más código en nuestras pruebas que en nuestra aplicación y la repetición es poco estética en comparación con la refinada concisión del resto de nuestro código.
\nNo importa, deje que crezcan. Por lo general, usted puede escribir una prueba una vez y luego olvidarse de ella. Esta seguirá cumpliendo su función útil mientras usted continúe desarrollando su programa.
\nA veces las pruebas tendrán que ser actualizadas. Supongamos que modificamos nuestras vistas de modo que sólo las Questions con Choices se publiquen. En ese caso, muchas de nuestras pruebas existentes fallarán, indicándonos exactamente qué pruebas necesitan ser modificadas para actualizarlas, de modo que hasta ese punto las pruebas ayudan a ocuparse de sí mismas.
En el peor de los casos, a medida que continúe desarrollando, usted podría encontrar que tiene algunas pruebas que ahora son redundantes. Incluso eso no es un problema, cuando se trata de pruebas, la redundancia es algo bueno.
\nSiempre y cuando las pruebas se organicen de forma razonable, no van a ser difíciles de manejar. Las reglas básicas de uso incluyen el hecho de tener:
\nuna TestClass independiente para cada modelo o vista
un método de prueba independiente para cada conjunto de condiciones que usted quiere probar
nombres de los métodos de prueba que describan su función
Este tutorial sólo presenta algunos de los temas fundamentales de las pruebas. Hay mucho más que usted puede hacer y una serie de herramientas muy útiles a su disposición para lograr algunas cosas muy interesantes.
\nPor ejemplo, aunque nuestras pruebas han tratado aquí algo de la lógica interna de un modelo y la forma en que nuestras vistas publican información, usted puede utilizar un framework «en el navegador» como Selenium para probar la forma en que su HTML en realidad se renderiza en un navegador. Estas herramientas le permiten comprobar no sólo el comportamiento de su código Django, sino también, por ejemplo, el de su JavaScript. ¡Es impresionante ver cómo las pruebas ejecutan un navegador y comienzan a interactuar con su sitio como si estuviese siendo operado por un humano! Django incluye LiveServerTestCase para facilitar la integración con herramientas como Selenium.
Si usted tiene una aplicación compleja, es posible que desee ejecutar las pruebas de forma automática con cada commit a efectos de la integración continua_, por lo que el control de calidad está en sí, al menos parcialmente, automatizado.
\nUna buena manera de detectar las partes de su aplicación que no han sido probadas es comprobar la cobertura de código. Esto también ayuda a identificar el código frágil o incluso muerto. Si no puede probar un trozo de código, por lo general significa que el código debe ser reestructurado o eliminado. La cobertura ayudará a identificar el código muerto. Consulte Integration with coverage.py para más detalles.
\nLas pruebas en Django tiene información completa acerca de las pruebas.
\nPara más detalles sobre las pruebas, consulte Las pruebas en Django.
\nCuando esté familiarizado con las pruebas de las vistas de Django, lea la parte 6 de este tutorial para aprender sobre la gestión de los archivos estáticos.
\n