Предисловие

Считается, что unit-тесты не должны использовать реальных объектов (т.е. подключений к базам данных, сетевых сокетов и подобного рода ресурсов). На этой почве развилось очень много холиваров — надо тестировать код, работающий с базами данных, или это плохой тон. Если тестировать, то можно ли это называть Unit-тестирование или это функциональное тестирование (или интеграционное, т.к. мы тестируем совместную работу двух программных сред/модулей). Споры и баталии не утихают. Я же попрошу читателей не отвлекаться на священные войны, а принять этот материал как пищу для размышления. Давайте не будем забывать, что описанное мною лишь инструмент, его применимость определяется задачей.

Выбор инструментов

Пожалуй самое сложное в Unit-тестировании — это проверка кода, работающего с подключениями к базам данных (по большому счету, проверка кода, работающего с внешними объектами). Да, можно использовать mock'и взамен подключений, но если у вас более одной операции с JDBC-провайдером, то вы с большей вероятностью сделаете ошибку в mock-объекте, чем отловите ее в коде при помощи последнего. Что же остается? Использовать реальные базы данных тоже нехорошо, ведь сервер БД в репозиторий не положишь… А если я скажу, что очень даже положишь, и он уже там находится? Решение нашей проблемы — HSQLDB.

HSQLDB — это реляционная база данных полностью написанная на Java. При этом, что очень примечательно, сервер базы данных может подниматься как отдельным инстансом, так и создаваться внутри Java-приложения. Небольшой размер и возможность полностью хранить всю базу данных в памяти (по умолчанию) делают HSQLDB идеальным сервером БД для Unit-тестирования. С учетом того, что с точки зрения JDBC и ORM реализация СУБД не имеет значения (если вы придерживаетесь стандарта SQL и не злоупотребляете расширениями движков СУБД), то мы с легкостью сможем подменить подключение к PostgreSQL или Oracle на соединение с HSQLDB при Unit-тестировании.

Хорошо, предположим, что у нас есть база данных, полностью размещающаяся в памяти и потребляющая минимальное количество ресурсов. Перед проведением тестов ее нужно заполнить данными, и желательно это делать методом более универсальным, чем написание SQL-запросов. Нам так же нужно проверять состояние базы данных после проведения операций над ней. Получать из нее данные и сверять их с эталоном вручную, согласитесь, идея крайне плохая. Поэтому, для решения проблемы инициализации и проверки результатов операции была создана библиотека DBUnit, идеально подходящая для автоматизации инициализации базы данных и последующей сверки наборов данных.

Про юнит тесты

Юнит тесты, как известно, это таблетка от головной боли разработчика ПО. Если использовать правильно и по инструкции, то здоровый цвет лица и блеск в глазах обеспечен и без стимулирующих средств. Про юнит тесты говорят по разному: с придыханием те кто прочитал о них в MSDN журнале, с восхищением те кто уже окунулся в мир прекрасного, и с сожалением те кто волею судеб вынужден работать в среде категорически неприемлющей эту ману небесную. Первым я могу лишь пожелать решительности, вторым апплодирую, а вот третим и адресована эта статья.

Кому это? О чем?

Данная статья посвящается таким же как и я, разработчикам корпоративных сайтов на C#/ASP.NET WebForms. Людям которые, как и я, доросли до осознания факта, что ASP.NET WebForms это классно, но не совсем. Не совсем, потому что вебформы не поддерживают юнит тесты, а следовательно и TDD. И единственный практический способ написания стойкого кода это вдумчивое чтение оного. Так я мучался последние несколько лет развивая существующие асп.нет проекты, пока наконец не прозрел. О прозрении и пойдет речь.

Проблема

Иногда нам необходимо протестировать скрытые (closure) функции или интерфейс, изолировав использование скрытых функций. Также порой требуется задать исходное состояние скрытых переменных или наоборот считать их состояние после теста. В этом случае мы строим дополнительный набор функций, обеспечивающий доступ внутрь объекта. Часто этот набор бывает очень громоздким и направлен только для обеспечения тестируемости модуля.

Но есть простой способ избежать написания этого кода.