Не буду говорить за все 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 комментария:
А какова вероятность возникновения такой ситуации (более 1000 типов документов) в реальной жизни? Если очень мала, то стоит ли это автоматизировать, ведь cost такого теста будет очень высок...
Кост может и высок, но тока, благодаря нашему фреймворку, тест был написан левой рукой за 10 минут.
Пример с типами документов - может и не реальный, НО, когда вы работаете с базами, в которых хранятся терабайты информации (у нас только 1 таблица с транзакциями занимала 1.5 терабайта), может возникнуть подобная проблема. Не отрицаю, что она выявится на этапе ревью, но кто его знает...
Я к тому, что многие часто любят увлекаться граничными условиями, исключительными ситуациями, экзотическими конфигурациями и т.п. А ведь реальный приоритет таких тестов не высок.
Я согласен, что не высок. Да и сильно увлекаться чем-то низко приоритетным смысла мало.
Но если есть возможность сэкономить время на тестировании, причем с маленькими затратами, то почему бы и нет.
Тут главное определить границу, за которую лучше не соваться :)
Отправить комментарий