Тестирование блока DatabaseOpenHelper в Android

Вместо того, чтобы проверить, что

• colum1 - это имя,
• colum2 - день рождения,
• colum3 is ....

Я бы просто проверить, существуют ли эти столбцы после обновления.

Чтобы сделать это, я бы создал интеграционный тест, который

• начинается с файла базы данных, который имеет старую версию базы данных,
• запустите программу обновления, а затем
• выполнить sql-select для каждой таблицы со всеми полями.

Пример:

• выберите имя, день рождения, номер телефона от клиента
• выберите orderid, orderdate, customerid из заказа

Test-Success означает, что исключение базы данных для неизвестной таблицы или поля отсутствует.

[Обновление 2.2.2013] Unittesting DatabaseOpenHelper (Unittest = Тестирование по отдельности) потребовал бы проверки без реальной базы данных и проверки подлинности сценария обновления базы данных или, по крайней мере, содержащего все необходимые поля /таблицы. На мой взгляд, это большая работа. Тестирование интеграции с реальной базой данных намного проще.

Может быть полезно сравнение схемы. У вас есть одна база данных, которая, как известно, имеет «правильную» схему. Это может быть копией базы данных разработки после замораживания кода. Затем создайте новую базу данных. Используйте инструмент сравнения, чтобы определить любые различия между двумя базами данных. Microsoft Visual Studio поставляется с инструментом сравнения схем. Существует несколько сторонних инструментов. Я использую собственный собственный инструмент сравнения, в котором перечислены все различия в 2 базах данных.

В качестве альтернативы вы можете просто проверить, выполняются ли сценарии создания схемы без ошибок. Скрипты ARE определение схемы, поэтому теоретически вам не нужно сравнивать или проверять что-либо, кроме факта, который они выполнили без ошибок.

Но по моему опыту люди вводят изменения в базу данных без их скриптинга. Инструмент сравнения может перехватывать эти неписанные изменения.

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

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

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

Мне не нравится время, необходимое для этого подхода, но это лучший справедливый подход, который я нашел.