вторник, 14 апреля 2009 г.

Oracle, SQL, IN - тестируем не тестируемое

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

Рассмотерим простейший запрос вида:

SELECT DOC_ID
FROM DOCUMENTS
WHERE DOC_TYPE IN ("1", "2", "3");

В результате мы получаем список документов с DOC_TYPE = 1, 2, 3. Это все ясно и понятно.

А теперь расскажу случай из жизни. Было такое вот не тестируемое требование:
Пользователь может добавить неограниченное количество документов.

Красиво, да?

Но как-то это надо тестировать!? :) Мы выкрутились следующим образом:

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

И в результате на следующий день "аппендикс вскрылся и тестовый юзер умер не приходя в сознание".

В чем же была причина смерти? Опытные патологоанатомы в лице наших разработчиков и DB админа быстро выявили причину смерти пациента:
- за день работы было создано больше 1000 типов документов, т.е. наш запрос превратился вот в такого монстра:


SELECT DOC_ID
FROM DOCUMENTS
WHERE DOC_TYPE IN ("1", "2", "3", "4", "5", "6", "7",
"8", "9", "10", "11", "12", "13", "14",
.....
"995", "996", "997", "998", "999", "1000", "1001","1002");

Как оказалось, в SQL есть ограничения на размер набора передаваемого в IN. И этот размер не должен превышать 1000 значений.

* * *

Дочитавшим до конца, хочу сказать, что какие бы ни были не тестируемые требования, вам все равно нужно проверить - на столько ли они не тестируемы :)

4 комментария:

bugsclock комментирует...

А какова вероятность возникновения такой ситуации (более 1000 типов документов) в реальной жизни? Если очень мала, то стоит ли это автоматизировать, ведь cost такого теста будет очень высок...

А.Б. комментирует...

Кост может и высок, но тока, благодаря нашему фреймворку, тест был написан левой рукой за 10 минут.

Пример с типами документов - может и не реальный, НО, когда вы работаете с базами, в которых хранятся терабайты информации (у нас только 1 таблица с транзакциями занимала 1.5 терабайта), может возникнуть подобная проблема. Не отрицаю, что она выявится на этапе ревью, но кто его знает...

bugsclock комментирует...

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

А.Б. комментирует...

Я согласен, что не высок. Да и сильно увлекаться чем-то низко приоритетным смысла мало.
Но если есть возможность сэкономить время на тестировании, причем с маленькими затратами, то почему бы и нет.
Тут главное определить границу, за которую лучше не соваться :)

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.