Як перевірити зчитувач файлів?

Я працюю над проектом з кількома форматами файлів. Деякі формати задаються .xsds, інші - документацією на відповідних веб-сайтах, а деякі - власні власні формати, які не мають документації. Мвахахахаха.

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

Я хотів би перевірити своїх читачів файлів, але я не зовсім впевнений, як це зробити. Потік програми є таким:

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з змінними, які я використовував для початкового створення файлу.

Однак у цього є кілька проблем:

• Файли , які він генерує , НЕ виглядають як справжні файли. Генератор жодним чином не усвідомлює контекст.
• Важко розпізнати, чи створив генератор для крайових випадків, оскільки я вручну встановлюю змінні. Цей метод ледве кращий за мене, створюючи десяток зразкових файлів.

Чи є кращі способи зробити це?

EDIT: Змінено одиницю на інтеграцію, оскільки саме це я маю на увазі.

EDIT2: Ось приклад кращих випадків, про які я згадав.

Кожен файл представляє графік, що складається з вершин і ребер. Ці вершини та ребра можуть бути прикріплені різними способами, так:

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

відрізняється від

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

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

Спочатку давайте поговоримо про ваші цілі:

• ви, очевидно, не хочете тестувати "формати файлів" - ви хочете протестувати різні ваші FileReaderреалізації

• ви хочете знайти якомога більше різних типів помилок за допомогою автоматичних тестів

Щоб досягти цілі в повному обсязі, ІМХО вам потрібно поєднувати різні стратегії:

• по-перше, тестування реального блоку: ваші FileReaderреалізації будуть складатися з безлічі різних частин і функцій. Напишіть невеликі тести, які кожне з них перевіряють ізольовано; спроектуйте свої функції таким чином, що їм насправді не потрібно читати дані з файлу. Цей вид тестів допоможе вам перевірити більшість ваших кращих справ.
• по-друге, згенеровані файли: це те, що я б назвав тестами інтеграції. Такі файли допоможуть вам відстежувати збої, відмінні від пункту 1, наприклад, комбінації конкретних параметрів, помилки в доступі до файлів тощо. класи еквівалентності або тестування граничних значень. Отримайте копію цієї книги Гленфорда Майерса, щоб дізнатися більше про це. Стаття у Вікіпедії про тестування програмного забезпечення також є хорошим ресурсом.
• по-третє, спробуйте отримати дані в реальному світі: важко переконатися, що ці файли оцінені правильно вашими FileReaders, але, можливо, варто це зробити, оскільки це часто виявляє помилки, не виявлені за першими двома стратегіями. Деякі люди називають такі речі також "інтеграційними тестами", інші вважають за краще "тести прийняття", але насправді термін насправді не має значення.

IMHO не існує "скороченого" підходу, який би приносив вам користь для всіх трьох стратегій "за ціну однієї". Якщо ви хочете виявити кращі випадки, а також збої як у звичайних випадках, так і в реальних випадках, вам доведеться вкласти принаймні деякі - швидше за все чималі - зусилля. На щастя, всі ці підходи можна використовувати для створення автоматичних повторюваних тестів.

Крім того, ви повинні переконатися, що ваш FileReaders не маскує жодних помилок під час читання цих даних - створюйте вбудовані перевірки / твердження, кидайте винятки, коли все відбувається не так внутрішньо тощо. Це дає вашому тестувальному коду набагато кращі шанси виявити помилки , навіть якщо у вас немає явного тестового файлу або тестового випадку для несподіваної ситуації.