¿Cómo pruebo un lector de archivos?

Estoy trabajando en un proyecto con algunos formatos de archivo. Algunos formatos están especificados por .xsds, otros por documentación en sus respectivos sitios web, y algunos son formatos personalizados internos que no tienen documentación. Mwahahahaha

¿Cuál es el problema?

Me gustaría probar mis lectores de archivos, pero no estoy completamente seguro de cómo hacerlo. El flujo de la aplicación es como tal:

file.___  ===> read by FileReader.java ===> which creates a Model object

donde está la FileReaderinterfaz

public interface FileReader {
    public Model read(String filename);
}

El Modeltiene una serie de atributos que se rellenan cuando se lee el archivo. Se parece a algo como

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

Que he probado

Mi única idea era crear "generadores" de archivos para cada formato de archivo. Estos generadores son básicamente constructores que toman algunas variables (por ejemplo, número de comentarios para generar en un archivo) y generan un archivo de muestra que luego leo y comparo el resultado Modelcon las variables que usé para generar inicialmente el archivo.

Sin embargo, esto tiene algunos problemas:

• Los archivos que genera no parecen archivos reales. El generador de ninguna manera es consciente del contexto.
• Es difícil reconocer si el generador ha generado casos extremos ya que yo soy el que configura manualmente las variables. Este método es apenas mejor que yo creando una docena de archivos de muestra.

¿Hay alguna forma mejor de hacer esto?

EDITAR: Cambié la unidad a la integración, ya que eso es lo que realmente quiero decir.

EDIT2: Aquí hay un ejemplo de los casos límite que mencioné.

Cada archivo representa un gráfico compuesto por vértices y aristas. Estos vértices y bordes se pueden unir de diferentes maneras, por lo tanto:

v1 -- e1 --> v2 <-- e2 -- v3

es diferente de

v1 -- e1 --> v2 -- e2 --> v3

en eso importa la dirección de los bordes. No estoy seguro de si esto está dentro del alcance de la pregunta, pero es difícil pensar en todos los casos de borde pertinentes cuando establezco manualmente el número de vértices, el número de bordes y solo genero las conexiones al azar.

Primero, hablemos sobre cuáles son sus objetivos:

• obviamente no desea probar "formatos de archivo" - desea probar sus diferentes FileReaderimplementaciones

• desea encontrar tantos tipos diferentes de errores como sea posible mediante pruebas automáticas

Para alcanzar esa meta en su totalidad, en mi humilde opinión, debes combinar diferentes estrategias:

• primero, pruebas de unidades reales: sus FileReaderimplementaciones consistirán en muchas partes y funciones diferentes. Escriba pequeñas pruebas que prueben cada una de ellas de forma aislada; diseñe sus funciones de manera que realmente no necesiten leer los datos de un archivo. Este tipo de pruebas lo ayudarán a evaluar la mayoría de sus casos límite.
• segundo, archivos generados: eso es lo que yo llamaría pruebas de integración. Dichos archivos lo ayudarán a rastrear fallas diferentes del punto 1, por ejemplo, combinaciones de parámetros específicos, errores en el acceso a archivos, etc. Para crear buenos casos de prueba, también será útil aprender algunas técnicas clásicas como agrupar casos de prueba en clases de equivalencia o prueba de valor límite. Obtenga una copia de este libro de Glenford Myers para obtener más información al respecto. El artículo de Wikipedia sobre pruebas de software también es un buen recurso.
• tercero, intente obtener datos del mundo real: puede ser difícil verificar que estos archivos sean evaluados correctamente por su FileReaders, pero puede valer la pena hacerlo, ya que a menudo encuentra errores no revelados por las dos primeras estrategias. Algunas personas llamarían a estas cosas amables también "pruebas de integración", otras prefieren "pruebas de aceptación", pero en realidad el término realmente no importa.

En mi humilde opinión, no existe un enfoque de "atajo" que le brinde el beneficio de las tres estrategias "por el precio de una". Si desea detectar casos extremos, así como fallas en los casos estándar y en los casos del mundo real, debe invertir al menos un esfuerzo, más probablemente mucho. Afortunadamente, todos esos enfoques se pueden utilizar para crear pruebas automáticas y repetibles.

Más allá de eso, debe asegurarse de que sus FileReadercorreos electrónicos no enmascaren ningún error al leer esos datos: cree verificaciones / aserciones incorporadas, arroje excepciones cuando algo salga mal internamente, etc. Esto le da a su código de prueba una oportunidad mucho mejor para detectar errores , incluso cuando no tiene un archivo de prueba explícito o un caso de prueba para una situación inesperada.