Prefacio: la universidad recibió una tarea: reunir un equipo scrum, seleccionar un proyecto y trabajar en él durante un semestre. Nuestro equipo eligió el desarrollo de aplicaciones web (reaccionar + matraz). En este artículo trataré de decirle qué pruebas deberían haber sido y analizar lo que hicimos en el backend.

Las expectativas

Las pruebas son necesarias, en primer lugar, para convencer a todos (incluidos nosotros mismos) de que el programa se comporta como debería en situaciones de prueba . En segundo lugar, aseguran el rendimiento del código cubierto por las pruebas en el futuro. Escribir pruebas es un proceso útil, porque en su proceso a menudo puede tropezar con áreas problemáticas, recordar algunos casos extremos, ver problemas con las interfaces, etc.

Al desarrollar cualquier sistema, debe recordar al menos tres tipos de pruebas:

• Las pruebas unitarias son pruebas que verifican que las funciones hacen lo que necesitan.
• Las pruebas de integración son pruebas que verifican que varias funciones juntas hacen lo correcto.
• Las pruebas del sistema son pruebas que verifican que todo el sistema hace lo que necesita.

En una de las publicaciones de google, se publicó una tabla con una descripción de tres tipos de pruebas. "Pequeño", "Medio" y "Grande".

Pruebas unitarias

Las pruebas unitarias corresponden a pruebas pequeñas: deben ser rápidas y solo verificar la corrección de partes específicas del programa. No deberían acceder a la base de datos, no deberían funcionar en entornos complejos de subprocesos múltiples. Controlan el cumplimiento de las especificaciones / estándares, a menudo tienen el papel de pruebas de regresión .

Pruebas de integración

Las pruebas de integración son aquellas que pueden afectar varios módulos y funciones. Dichas pruebas requieren más tiempo y pueden requerir entornos especiales. Son necesarios para asegurarse de que los módulos y las funciones individuales puedan funcionar entre sí. Es decir las pruebas unitarias verifican la conformidad de las interfaces reales con las esperadas, y las pruebas de integración, que las funciones y los módulos interactúan correctamente entre sí.

Pruebas del sistema

Este es el nivel más alto de pruebas automáticas. Las pruebas del sistema verifican que todo el sistema funciona, que sus partes realizan sus tareas y pueden interactuar correctamente.

¿Por qué hacer un seguimiento de los tipos?

Por lo general, con el crecimiento del proyecto, la base del código también crecerá. La duración de las verificaciones automáticas aumentará; admitir una gran cantidad de pruebas de integración y del sistema será cada vez más difícil. Por lo tanto, el desafío para los desarrolladores es minimizar las pruebas necesarias. Para hacer esto, intente usar pruebas unitarias cuando sea posible y reduzca la integración usando "simulacros" (simulacros).

Realidad

Prueba típica de API

def test_user_reg(client): return json.loads( client.post(url, json=data, content_type='application/json').data ) response = client.post('api/user.reg', json={ 'email': 'name@mail.ru', 'password': 'password1', 'first_name': 'Name', 'last_name': 'Last Name' }) data = json.loads(response.data) assert data['code'] == 0 

De la documentación oficial del matraz, obtenemos una receta preparada para inicializar la aplicación y crear la base de datos. Aquí está el trabajo con la base de datos. Esta no es una prueba unitaria, pero no es una prueba del sistema. Esta es una prueba de integración que utiliza una aplicación de prueba de base de datos.

¿Por qué integración en lugar de modular? Porque en el procesamiento de consultas, la interacción se realiza con el matraz, con ORM, con nuestra lógica de negocios. Los controladores actúan como un enlace unificador de otras partes del proyecto, por lo que escribir pruebas unitarias para ellos no es demasiado fácil (necesita reemplazar la base de datos con simulacros, lógica interna) y no es demasiado práctico (las pruebas de integración verifican aspectos similares: "¿se llamaron las funciones necesarias?", " ¿Se recibieron correctamente los datos? ", Etc.).

Nombres y agrupación de pruebas.

 def test_not_empty_errors(): assert validate_not_empty('email', '') == ('email is empty',) assert validate_not_empty('email', ' ') == ('email is empty',) assert validate_email_format('email', "") == ('email is empty',) assert validate_password_format('pass', "") == ('pass is empty',) assert validate_datetime('datetime', "") == ('datetime is empty',) 

En esta prueba, se cumplen todas las condiciones para las pruebas "pequeñas": se verifica que el comportamiento de la función sin dependencias cumpla con lo esperado. Pero el diseño plantea preguntas.

Es una buena práctica escribir pruebas que se centren en un aspecto específico del programa. En este ejemplo, hay diferentes funciones: validate_password_format , validate_password_format , validate_datetime . Las comprobaciones de agrupamiento no se basan en el resultado, sino en los objetos de prueba.

El nombre de la prueba ( test_not_empty_errors ) no describe el objeto de prueba (qué método se está probando), solo describe el resultado (los errores no están vacíos). Este método debe llamarse test__validate_not_empty__error_on_empty . Este nombre describe lo que se está probando y qué resultado se espera. Esto se aplica a casi todos los nombres de prueba en el proyecto debido al hecho de que no se tomó tiempo para discutir las convenciones de nombres de prueba.

Pruebas de regresión

 def test_datetime_errors(): assert validate_datetime('datetime', '0123-24-31T;431') == ('datetime is invalid',) assert validate_datetime('datetime', '2018-10-18T20:21:21+-23:1') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-13-20T20:20:20+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-02-29T20:20:20+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T25:20:20+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:61:20+22:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:20:61+20:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:20:20+25:20') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-12-20T20:20:20+20:61') == ('datetime is invalid',) assert validate_datetime('datetime', '2015-13-35T25:61:61+61:61') == ('datetime is invalid',) 

Esta prueba originalmente consistió en las dos primeras assert . Después de eso, se descubrió un "error": en lugar de verificar la fecha, solo se verificó la expresión regular, es decir 9999-99-99 se consideró una fecha normal. El desarrollador lo arregló. Naturalmente, después de corregir el error, debe agregar pruebas para evitar una regresión futura. En lugar de agregar una nueva prueba en la que escribir por qué existe esta prueba, se agregaron cheques a esta prueba.

¿Cómo debería llamarse una nueva prueba para agregar la verificación? Probablemente test__validate_datetime__error_on_bad_datetime .

Ignorando las herramientas

 def test_get_providers(): class Tmp: def __init__(self, id_external, token, username): self.id_external = id_external self.token = token self.username = username ... 

Tmp ? Esta es una sustitución de un objeto que no se usa en esta prueba. El desarrollador no parece saber sobre la existencia de @patch y MagicMock de unittest.mock . No es necesario complicar el código resolviendo problemas ingenuamente cuando hay herramientas más adecuadas.

Existe una prueba que inicializa los servicios (en la base de datos) y utiliza el contexto de la aplicación.

 def test_get_posts(client): def fake_request(*args, **kwargs): return [one, two] handler = VKServiceHandler() handler.request = fake_request services_init() with app.app_context(): posts = handler.get_posts(None) assert len(posts) == 2 

Puede excluir la base de datos y el contexto de la prueba simplemente agregando un @patch .

 @patch("mobius.services.service_vk.Service") def test_get_posts(mock): def fake_request(*args, **kwargs): return [one, two] handler = VKServiceHandler() handler.request = fake_request posts = handler.get_posts(None) assert len(posts) == 2 

Resumen

• Para desarrollar software de calidad, debe escribir pruebas. Como mínimo, para asegurarse de escribir lo que necesita.
• Para sistemas de información grandes, las pruebas son aún más importantes: le permiten evitar cambios de interfaz no deseados o errores de retorno.
• Para que las pruebas escritas no se conviertan en muchos métodos extraños con el tiempo, debe prestar atención a la convención de nomenclatura de las pruebas, cumplir con las buenas prácticas y minimizar las pruebas.
• Las pruebas unitarias pueden ser una gran herramienta durante el desarrollo. Se pueden ejecutar después de cada pequeño cambio para asegurarse de que no se rompa nada.

Un punto muy importante es que las pruebas no garantizan la disponibilidad o ausencia de errores. Las pruebas aseguran que se espera el resultado real del programa (o parte de él). En este caso, la verificación solo ocurre para aquellos aspectos para los cuales se escribieron las pruebas. Por lo tanto, al crear un producto de calidad, no debemos olvidarnos de otros tipos de pruebas.