Modificaciones de Archivos de Pruebas Unitarias

Tienes dos niveles de prueba.

1. Filtrar y Modificar contenido. Estas son operaciones de "bajo nivel" que realmente no requieren E/S de archivos físicos.Estas son las pruebas, la toma de decisiones, las alternativas, etc. La "Lógica" de la aplicación.

2. Operaciones del sistema de archivos. Crear, copiar, cambiar el nombre, eliminar, copia de seguridad. Lo siento, pero esas son las operaciones del sistema de archivos que require bueno require requieren un sistema de archivos adecuado para las pruebas.

Para este tipo de probando, a menudo usamos un objeto "Simulado". Puede diseñar una clase "FileSystemOperations" que encarne las diversas operaciones del sistema de archivos. Usted prueba esto para asegurarse de que lo hace básico leer, escribir, copiar, cambiar el nombre, etc. No hay lógica real en esto. Solo métodos que invocan operaciones del sistema de archivos.

A continuación, puede crear un MockFileSystem que dummies a cabo las diversas operaciones. Puedes usar este objeto Simulado para probar tus otras clases.

En algunos casos, todas las operaciones del sistema de archivos están en el módulo del sistema operativo. Si ese es el caso, puede crear un módulo MockOS con una versión simulada de las operaciones que realmente utiliza.

Ponga su módulo MockOS en el PYTHONPATH y puede ocultar el módulo del sistema operativo real.

Para las operaciones de producción utiliza sus clases "Logic" bien probadas más su clase FileSystemOperations (o el módulo real OS).)

Para lectores posteriores que solo quieren una forma de probar que la escritura de código en archivos funciona correctamente, aquí hay un "fake_open" que parchea el builtin abierto de un módulo para usar StringIO. fake_open devuelve un dict de archivos abiertos que pueden ser examinados en una prueba unitaria o doctest, todo sin necesidad de un sistema de archivos real.

def fake_open(module):
    """Patch module's `open` builtin so that it returns StringIOs instead of
    creating real files, which is useful for testing. Returns a dict that maps
    opened file names to StringIO objects."""
    from contextlib import closing
    from StringIO import StringIO
    streams = {}
    def fakeopen(filename,mode):
        stream = StringIO()
        stream.close = lambda: None
        streams[filename] = stream
        return closing(stream)
    module.open = fakeopen
    return streams

Cuando toco archivos en mi código, tiendo a preferir burlarme de la lectura y escritura real del archivo... entonces puedo dar a mis clases el contenido exacto que quiero en la prueba, y luego afirmar que la prueba está escribiendo de nuevo el contenido que espero.

He hecho esto en Java, y me imagino que es bastante simple en Python... pero puede requerir diseñar sus clases / funciones de tal manera que sea FÁCIL burlarse del uso de un archivo real.

Para esto, puede intentar pasar secuencias y a continuación, simplemente pase una secuencia de entrada/salida de cadena simple que no escriba en un archivo, o tenga una función que haga el real "escribir esta cadena en un archivo" o "leer esta cadena de un archivo", y luego reemplace esa función en sus pruebas.

Creo que estás en el camino correcto. Dependiendo de lo que necesite hacer chroot puede ayudarlo a configurar un entorno para sus scrpits que 'se ve' real, pero no lo es.

Si eso no funciona, entonces podría escribir sus scripts para tomar una ruta 'raíz' como argumento.

En una ejecución de producción la ruta raíz es simplemente /. Para probar, cree un entorno de sombra bajo /tmp / test y luego ejecute sus scripts con una ruta raíz de / tmp / test.

Es posible que desee configurar la prueba para que se ejecute dentro de una jaula de chroot, para que tenga todo el entorno que necesita la prueba, incluso si las rutas y las ubicaciones de los archivos están codificadas en el código [no es realmente una buena práctica, pero a veces uno obtiene las ubicaciones de los archivos de otros lugares...] y luego verifique los resultados a través del código de salida.