Тестирование методов, возвращающие сложные объекты

Привет!

Тестируется все JUnit.

Вот вопрос тут возник. Если методы, которые возвращают коллекции объектов. Руками их создавать - ломает: и коллекции не маленькие и объекты там тоже не простые.

Вот и подумалось - а, может, сериализовать эталонные результаты, а потом сравнивать с ними? Правда, после педактирования класса коллекции придется заново сохранять результаты тестов.

Что по этому поводу народ думает?

0

Лично мне кажется, что если в модульном тесте идёт работа с большим объёмом разнородных данных, то это уже не модульный, а интеграционный тест. Соответственно подход должен быть совсем другим.

Ну а если ближе к теме, то можно предложить кое-что:

1) Возможно для целей тестирования не обязательно проверять содержимое всей коллекции, а достаточно просто проверить наличие/отсутствие в ней ключевых элементов методами типа Collection.contains() или Map.containsKey().

2) Откуда-то этот большой объём данных берётся. Если метод их не генерит сам, то значит на вход ему поступает (или извлекается из контекста) тоже большой объём информации. Соответственно, можно было бы проверить работу метода на меньшем объёме входной информации.

3) Попробовать непосредственно тестировать те объекты, которые используются при реализации вашего метода. Если ваш метод большой и толстый, но при этом не использует какие-то другие объекты, то возможно стоит задуматься о разделении логики метода между несколькими объектами и тестировать уже их.

Если вы действительно хотите выполнить интеграционное тестирование, то использование прегенерированных тестовых данных вполне уместно. Вот только всё равно эти данные как-то нужно создать, то есть написать соответствующий код. Тогда почему бы не включить этот код в сам тест?

0

Блин! Писал-писал! А оно все сломалось!

Спасибо за ответ.

Данные в тесте получаются из базы, туда они запихиваются dbunit.

А так подумал, наверное, действительно не надо сериализовать коллекции, а сравнивать какие-нибудь суммы из них(типа CRC). Если сравнить достаточно много сумм, то можно говорить о соответствии результатов.

Спасибо за идею!

0

Приятно подавать идеи

Есть ещё вариант, который может существенно упростить тестирование: использование mock-объектов. Суть в том, чтобы тестировать не состояние после выполнения определённых действий, а сам ход выполнения действий. В вашем случае, например, можно было бы всего-лишь протестировать корректность запросов, которые даются СУБД.

Подробнее, можно почитать тут: http://www.martinfowler.com/articles/mocksArentStubs.html

а тут скачать сами инструменты:
http://www.jmock.org
http://www.easymock.org

0

>>Приятно подавать идеи
Ну дык! Мы все из страны советов :-)

>>Есть ещё вариант, который может существенно упростить тестирование:
...
>>лишь протестировать корректность запросов, которые даются СУБД.
Там всего один запрос, который возвращает коллекцию строк из базы. А вот дальше ее обрабатывают другие методы. Про мок объекты я, конечно, знаю, но не могу понять как их тут использовать.

Надо будет разобраться с ними по-подробнее.

Еще раз спасибо!

0

>> Вот и подумалось - а, может, сериализовать эталонные результаты, а потом сравнивать с ними? Правда, после педактирования класса коллекции придется заново сохранять результаты тестов.

Если используете Spring framework, то эталлоные результаты можно обьявить в отдельном конфиг.файле и включить этот конфиг файл в ваш тест.класс.
Начиная с версии 1.1.4 есть возможность юзать вот этот класс, не чистив базу после теста; смотрите подробности:
http://static.springframework.org/spring/docs/1.1.5/api/index.html

0

Ага! Спасибо! Посмотрю!

0