Pytest dónde almacenar los datos esperados

Función de prueba Necesito pasar parámetros y ver que la salida coincida con la salida esperada.

Es fácil cuando la respuesta de la función es solo una pequeña matriz o una cadena de una línea que se puede definir dentro de la función de prueba, pero supongamos que la función que pruebo modifica un archivo de configuración que puede ser enorme. O la matriz resultante tiene una longitud de 4 líneas si la defino explícitamente. ¿Dónde lo guardo para que mis pruebas permanezcan limpias y fáciles de mantener?

En este momento, si eso es una cadena, simplemente coloco un archivo cerca del .py probar y hacer open() dentro de la prueba:

def test_if_it_works():
    with open('expected_asnwer_from_some_function.txt') as res_file:
        expected_data = res_file.read()
    input_data = ... # Maybe loaded from a file as well
    assert expected_data == if_it_works(input_data)

Veo muchos problemas con este enfoque, como el problema de mantener este archivo actualizado. Se ve mal también. Puedo hacer las cosas probablemente mejor moviendo esto a un accesorio:

@pytest.fixture
def expected_data()
    with open('expected_asnwer_from_some_function.txt') as res_file:
        expected_data = res_file.read()
    return expected_data

@pytest.fixture
def input_data()
    return '1,2,3,4'

def test_if_it_works(input_data, expected_data):
    assert expected_data == if_it_works(input_data)

Eso solo mueve el problema a otro lugar y, por lo general, necesito probar si la función funciona en caso de entrada vacía, entrada con un solo elemento o múltiples elementos, por lo que debería crear un gran dispositivo que incluya los tres casos o múltiples dispositivos. Al final, el código se vuelve bastante desordenado.

Si una función espera un diccionario complicado como entrada o devuelve el diccionario del mismo tamaño enorme, el código de prueba se vuelve feo:

 @pytest.fixture
 def input_data():
     # It's just an example
     return {['one_value': 3, 'one_value': 3, 'one_value': 3,
     'anotherky': 3, 'somedata': 'somestring'], 
      ['login': 3, 'ip_address': 32, 'value': 53, 
      'one_value': 3], ['one_vae': 3, 'password': 13, 'lue': 3]}

Es bastante difícil leer las pruebas con estos accesorios y mantenerlos actualizados.

Actualizar

Después de buscar un rato, encontré una biblioteca que resolvió una parte de un problema cuando, en lugar de grandes archivos de configuración, tenía grandes respuestas HTML. Es betamax.

Para un uso más fácil, creé un accesorio:

from betamax import Betamax

@pytest.fixture
def session(request):
    session = requests.Session()
    recorder = Betamax(session)
    recorder.use_cassette(os.path.join(os.path.dirname(__file__), 'fixtures', request.function.__name__)
    recorder.start()
    request.addfinalizer(recorder.stop)
    return session

Así que ahora en mis pruebas solo uso el session accesorio y cada solicitud que hago se serializa automáticamente en el fixtures/test_name.json para que la próxima vez que ejecute la prueba, en lugar de hacer una biblioteca de solicitud HTTP real, la cargue desde el sistema de archivos:

def test_if_response_is_ok(session):
   r = session.get("http://google.com")

Es bastante útil porque para mantener estos accesorios actualizados solo necesito limpiar el fixtures carpeta y vuelva a ejecutar mis pruebas.

Tuve un problema similar una vez, donde tengo que probar el archivo de configuración contra un archivo esperado. Así lo arreglé:

1. Cree una carpeta con el mismo nombre de su módulo de prueba y en la misma ubicación. Ponga todos sus archivos esperados dentro de esa carpeta.

   test_foo/
       expected_config_1.ini
       expected_config_2.ini
   test_foo.py
   

2. Cree un accesorio responsable de mover el contenido de esta carpeta a un archivo temporal. hice uso de tmpdir accesorio para este asunto.

   from __future__ import unicode_literals
   from distutils import dir_util
   from pytest import fixture
   import os
   
   
   @fixture
   def datadir(tmpdir, request):
       '''
       Fixture responsible for searching a folder with the same name of test
       module and, if available, moving all contents to a temporary directory so
       tests can use them freely.
       '''
       filename = request.module.__file__
       test_dir, _ = os.path.splitext(filename)
   
       if os.path.isdir(test_dir):
           dir_util.copy_tree(test_dir, bytes(tmpdir))
   
       return tmpdir
   

   Importante: Si está utilizando Python 3, reemplace dir_util.copy_tree(test_dir, bytes(tmpdir)) con dir_util.copy_tree(test_dir, str(tmpdir)).

3. Usa tu nuevo accesorio.

   def test_foo(datadir):
       expected_config_1 = datadir.join('expected_config_1.ini')
       expected_config_2 = datadir.join('expected_config_2.ini')
   

Recordar: datadir es lo mismo que tmpdir accesorio, además de la capacidad de trabajar con los archivos esperados colocados en una carpeta con el mismo nombre de módulo de prueba.

Yo creo Pytest-archivos de datos puede ser de gran ayuda. Desafortunadamente, parece que ya no se mantiene mucho. Por el momento, está funcionando bien.

Aquí hay un ejemplo simple tomado de los documentos:

import os
import pytest

@pytest.mark.datafiles('/opt/big_files/film1.mp4')
def test_fast_forward(datafiles):
    path = str(datafiles)  # Convert from py.path object to path (str)
    assert len(os.listdir(path)) == 1
    assert os.path.isfile(os.path.join(path, 'film1.mp4'))
    #assert some_operation(os.path.join(path, 'film1.mp4')) == expected_result

    # Using py.path syntax
    assert len(datafiles.listdir()) == 1
    assert (datafiles / 'film1.mp4').check(file=1)

Si solo tiene algunas pruebas, ¿por qué no incluir los datos como una cadena literal?

expected_data = """
Your data here...
"""

Si tiene un puñado, o los datos esperados son realmente largos, creo que su uso de accesorios tiene sentido.

Sin embargo, si tiene muchos, quizás una solución diferente sería mejor. De hecho, para un proyecto tengo más de cien archivos de entrada y salida esperada. Así que construí mi propio marco de prueba (más o menos). Usé Nose, pero PyTest también funcionaría. Creé un generador de prueba que recorrió el directorio de archivos de prueba. Para cada archivo de entrada, se realizó una prueba que comparaba la salida real con la salida esperada (PyTest lo llama parametrización). Luego documenté mi marco para que otros pudieran usarlo. Para revisar y/o editar las pruebas, solo edita los archivos de entrada y/o salida esperados y nunca necesita mirar el archivo de prueba de python. Para permitir que diferentes archivos de entrada tengan diferentes opciones definidas, también creé un archivo de configuración YAML para cada directorio (JSON también funcionaría para mantener bajas las dependencias). Los datos YAML consisten en un diccionario donde cada clave es el nombre del archivo de entrada y el valor es un diccionario de palabras clave que pasarán a la función que se está probando junto con el archivo de entrada. Si estás interesado, aquí está el código fuente y documentación. Recientemente jugué con la idea de definir las opciones como Unittests aquí (requiere solo la lib unittest incorporada) pero no estoy seguro de si me gusta.

Piense si todo el contenido del archivo de configuración realmente necesita ser probado.

Si solo se deben verificar varios valores o subcadenas, prepare una plantilla esperada para esa configuración. Los lugares probados se marcarán como “variables” con alguna sintaxis especial. Luego prepare una lista esperada separada de los valores para las variables en la plantilla. Esta lista esperada se puede almacenar como un archivo separado o directamente en el código fuente.

Ejemplo para la plantilla:

ALLOWED_HOSTS = ['{host}']
DEBUG = {debug}
DEFAULT_FROM_EMAIL = '{email}'

Aquí, las variables de la plantilla se colocan entre llaves.

Los valores esperados pueden verse como:

host = www.example.com
debug = False
email = webmaster@example.com

o incluso como una simple lista separada por comas:

www.example.com, False, webmaster@example.com

Luego, su código de prueba puede producir el archivo esperado a partir de la plantilla reemplazando las variables con los valores esperados. Y el archivo esperado se compara con el real.

Mantener la plantilla y los valores esperados por separado tiene la ventaja de que puede tener muchos conjuntos de datos de prueba usando la misma plantilla.

Probando solo variables

Un enfoque aún mejor es que el método de generación de configuración produce solo los valores necesarios para el archivo de configuración. Estos valores se pueden insertar fácilmente en la plantilla mediante otro método. Pero la ventaja es que el código de prueba puede comparar directamente todas las variables de configuración por separado y de manera clara.

Plantillas

Si bien es fácil reemplazar las variables con los valores necesarios en la plantilla, existen bibliotecas de plantillas listas, que permiten hacerlo solo en una línea. Estos son solo algunos ejemplos: Django, Jinja, mako