Как я могу проверить читатель файла?

Я работаю над проектом с несколькими форматами файлов. Некоторые форматы определяются .xsds, другие - документацией на соответствующих веб-сайтах, а некоторые являются собственными внутренними форматами, которые не имеют документации. Mwahahahaha.

В чем проблема?

Я хотел бы проверить свои программы для чтения файлов, но я не совсем уверен, как это сделать. Поток приложения таков:

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

где FileReaderинтерфейс

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

ModelИмеет ряд атрибутов , которые заполняются при чтении файла. Это выглядит примерно так

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

Что я пробовал?

Моя единственная идея состояла в том, чтобы создать файловые «генераторы» для каждого формата файла. Эти генераторы в основном являются компоновщиками, которые принимают несколько переменных (например, количество комментариев для генерации в файле) и выводят образец файла, который я затем читаю, и сравнивают полученный результат Modelс переменными, которые я использовал для первоначальной генерации файла.

Это имеет несколько проблем:

• Файлы, которые он генерирует, не похожи на реальные файлы. Генератор не знает контекста.
• Трудно распознать, сгенерирован ли генератор для граничных случаев, так как я задаю переменные вручную. Этот метод едва ли лучше, чем я, создающий дюжину примеров файлов.

Есть ли лучшие способы сделать это?

РЕДАКТИРОВАТЬ: изменение единицы для интеграции, поскольку это то, что я на самом деле имею в виду.

РЕДАКТИРОВАТЬ 2: Вот пример крайних случаев, которые я упомянул.

Каждый файл представляет собой граф, состоящий из вершин и ребер. Эти вершины и ребра могут быть присоединены по-разному, поэтому:

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

отличается от

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

в этом направлении края имеют значение. Я не уверен, входит ли это в суть вопроса, но сложно придумать все подходящие случаи ребер, когда я вручную устанавливаю количество вершин, количество ребер и просто генерирую соединения случайным образом.

Во-первых, давайте поговорим о ваших целях:

• вы явно не хотите тестировать «форматы файлов» - вы хотите протестировать различные FileReaderреализации

• вы хотите найти как можно больше различных типов ошибок с помощью автоматических тестов

Чтобы полностью достичь этой цели, ИМХО нужно сочетать разные стратегии:

• во-первых, реальное модульное тестирование: ваши FileReaderреализации будут состоять из множества различных частей и функций. Напишите небольшие тесты, которые тестируют каждый из них в отдельности; Разработайте свои функции таким образом, чтобы им не нужно было считывать данные из файла. Такие тесты помогут вам протестировать большинство ваших крайних случаев.
• во-вторых, сгенерированные файлы: это то, что я бы назвал интеграционными тестами. Такие файлы помогут вам отследить сбои, отличные от пункта 1, например, комбинации определенных параметров, ошибки в доступе к файлам и т. Д. Для создания хороших тестовых примеров будет также полезно узнать о некоторых классических методах, таких как группировка тестовых примеров в классы эквивалентности или граничное тестирование. Получить копию этой книги Гленфорд Майерс, чтобы узнать больше об этом. Статья Википедии о тестировании программного обеспечения является хорошим ресурсом, тоже.
• в-третьих, попытайтесь получить реальные данные: может быть трудно проверить, правильно ли эти файлы оцениваются вашими пользователями FileReader, но, возможно, стоит сделать это, поскольку часто обнаруживаются ошибки, не обнаруженные в первых двух стратегиях. Некоторые люди называют эти добрые вещи также «интеграционными тестами», другие предпочитают «приемочные тесты», но на самом деле этот термин не имеет большого значения.

ИМХО, не существует «быстрого» подхода, который принес бы вам пользу от всех трех стратегий «по цене одной». Если вы хотите выявлять крайние случаи, а также сбои в стандартных случаях, а также в реальных случаях, вы должны инвестировать, по крайней мере, некоторые - более вероятно, много - усилия. К счастью, все эти подходы могут быть использованы для создания автоматических повторяемых тестов.

Кроме того, вы должны убедиться, что ваши FileReaderфайлы не маскируют ошибки при чтении этих данных - создавайте встроенные проверки / утверждения, создавайте исключения, когда что-то идет не так, внутренне и т. Д. Это дает вашему тестовому коду гораздо больше шансов обнаружить ошибки даже если у вас нет явного тестового файла или тестового примера для непредвиденной ситуации.