Тестирование CRUD, часть 2 – обновление и удаление |
14.11.2019 00:00 | |||||||||||||||||||||||||||||||||||||||||||||
Автор: Кристин Джеквони (Kristin Jackvony) В прошлый раз мы начали разбираться с тестированием CRUD. Как вы помните, CRUD означает "Create, Read, Update, Delete" (создание, чтение, обновление и удаление). В прошлый раз мы обсуждали тестирование создания и чтения, а теперь рассмотрим обновление и удаление. Обсуждая операцию чтения, я упоминала, как важно тестировать сценарии, при которых данные в базе неверны. Это верно и для операции обновления. Только то, что текстовое поле предполагается обязательным и должно разрешать определенное количество символов, не означает, что именно так работает ваша база данных! Ниже – матрица тест-сценариев для редактирования текстового поля. Если вы помните, наше гипотетическое поле имеет следующие правила валидации: оно обязательное, в нем должно быть не менее двух и не более сорока символов, и оно должно разрешать только буквы, дефисы и апострофы – все прочие символы запрещены. Как и при операции создания, убедитесь, что отредактированные поля корректны как в интерфейсе, так и в базе данных после обновления.
Убедитесь, что вы варьируете свои плохие данные, чтобы покрыть несколько различных сценариев валидации. Для хороших данных не забудьте проверить апострофы и дефисы, цифры и буквы, а также верхний и нижний предел количества символов. И, наконец, обсудим удаление. Главное, что тут нужно проверить – удаление значения и в интерфейсе, и в базе данных. Однако как и в случаях с чтением и обновлением, нужно убедиться, что плохие данные можно удалить. К примеру, Если в имени 41 символ (нарушается правило "не более 40 символов), нужно убедиться, что его можно удалить через интерфейс. Возможно, вы думаете, где найти "плохие" данные для тестирования. Их, конечно, можно обнаружить в существующих записях, но самый простой способ – добавить их самостоятельно! Поэтому так важно знать нужный язык запросов – например, SQL – к вашей базе данных. Если вы размышляете, почему тестирование плохих данных так важно, приведу пример. Один раз я тестировала контактную информацию. В базе данных было несколько неправильно отформатированных телефонных номеров. Когда я пыталась обновить контактную информацию для этого человека, то получала сообщение, что это невозможно, так как присутствуют невалидные данные. Это происходило, даже если я пыталась отредактировать эти самые неправильные номера телефонов! Убедитесь, что вы проверяете такие сценарии – ваш пользователь скажет вам спасибо! |