Как писать тесты для БД?[re: Про unit-тесты для кода..]
Если сторонники тестов подскажут, как надо, буду весьма признателен.Знаешь, уже лучше начать новую тему. В этой слишком сильно увлеклись обсуждением, гениален Шурик или нет. Лично мне этого пока что не заметно, и даже наоборот.
хочется решить какую-то конкретную проблему? или интересует вообще?
Тестировать из БД нереально - процедура может возвращать нужные данные, но система их может не понять.Можешь уточнить, как вообще работает эта программа? А это у меня от этой фразы возникает когнитивный диссонанс. Если вы вернули данные, которые не понимает система - это ошибка, то есть вы вернули ненужные данные.
Эта проблема скорее не так актуальна, да и тесты для этого сейчас написаны. Такое возникало, когда случайно меняли названия колонок в результатах. Это происходило часто, ибо колонки именуются зачастую по-французски.
Сейчас есть тесты на названия колонок и на тестирование производительности. Последние приходится постоянно менять, ибо меняются требования.
Вообще интересет подход к тестированию базы. Тут важно не отработало-не отработало, а валидность данных. В некоторых случаях можно проверять количество строк, в некоторых - какую-нибудь контрольную сумму. Но в любом случае написание тестов получается довольно дорогим удовольствием - разработка ведется именно в базе, и любое изменение влечет изменение тестов. Буду рад, если кто подскажет, как надо делать
Сейчас есть тесты на названия колонок и на тестирование производительности. Последние приходится постоянно менять, ибо меняются требования.
Вообще интересет подход к тестированию базы. Тут важно не отработало-не отработало, а валидность данных. В некоторых случаях можно проверять количество строк, в некоторых - какую-нибудь контрольную сумму. Но в любом случае написание тестов получается довольно дорогим удовольствием - разработка ведется именно в базе, и любое изменение влечет изменение тестов. Буду рад, если кто подскажет, как надо делать
Но в любом случае написание тестов получается довольно дорогим удовольствиемПри написании тестов есть tradeoff, но они всегда окупают себя в долгосрочной перспективе. Вкратце: сокращают регрессию, помогают при рефакторинге, улучшают твоё собственное понимание происходящего.
Буду рад, если кто подскажет, как надо делатьПрактически нереально добавить тесты в системы, которые изначально на это не рассчитывались. Я не разрабатывал программное обеспечение "внутри" БД, но если бы мне пришлось это делать, то функциональные тесты я бы написал на языке программирования (на Java). Тогда можно было бы менять что угодно "внутри" БД, сохраняя работоспособность всех "внешних" запросов.
Оставить комментарий
hprt
А можно вернуться к начальной задаче?На самом деле, интересно. Я согласен с Шуриком, что тесты для БД писать напряжно, дальше наши взгляды расходятся, но это не важно. Если сторонники тестов подскажут, как надо, буду весьма признателен. Тестировать из БД нереально - процедура может возвращать нужные данные, но система их может не понять. На один тест через приложение уходит минут 5 минимум. Я готов ждать данных хоть час, но там, блин, мышкой тыкать надо.
Итак, есть отчетная система, мы пишем библиотеки по доставанию данных из базы. Остальное мы не имеем права менять. Фактически код сайта мы не меняем вообще - там только дергаются процедуры. Мы даже названия колонок не можем менять.
Мы пишем процедуры в базе. Что меняется - ограничивается выборка по правам, меняется логика расчета, оптимизируются запросы. Если с оптимизацией все понятно - сохранили резалтсет, проверили, что все то же самое возвращает, то что делать в других случаях?