Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Тестирование CRUD, часть 2 – обновление и удаление
14.11.2019 00:00

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

В прошлый раз мы начали разбираться с тестированием CRUD. Как вы помните, CRUD означает "Create, Read, Update, Delete" (создание, чтение, обновление и удаление). В прошлый раз мы обсуждали тестирование создания и чтения, а теперь рассмотрим обновление и удаление.

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

Ниже – матрица тест-сценариев для редактирования текстового поля. Если вы помните, наше гипотетическое поле имеет следующие правила валидации: оно обязательное, в нем должно быть не менее двух и не более сорока символов, и оно должно разрешать только буквы, дефисы и апострофы – все прочие символы запрещены. Как и при операции создания, убедитесь, что отредактированные поля корректны как в интерфейсе, так и в базе данных после обновления.

Исходное значение

Отредактированное значение

Ожидаемый результат

NULL

" " (пустая строка)

Сообщение об ошибке. БД без изменений.

NULL

Плохое значение: менее двух символов, более сорока, или содержит спецсимволы (кроме дефиса и апострофа).

Сообщение об ошибке. БД без изменений.

NULL

Хорошие данные

Новое значение сохранено в базе данных.

" "

NULL

Сообщение об ошибке. БД без изменений.

" "

Плохие данные

Сообщение об ошибке. БД без изменений.

" "

Хорошие данные

Новое значение сохранено в базе данных

Плохие данные

NULL

Сообщение об ошибке. БД без изменений.

Плохие данные

" "

Сообщение об ошибке. БД без изменений.

Плохие данные

Иные плохие данные.

Сообщение об ошибке. БД без изменений.

Плохие данные

Хорошие данные

Новое значение сохранено в базе данных

Хорошие данные

NULL

Сообщение об ошибке. БД без изменений.

Хорошие данные

" "

Сообщение об ошибке. БД без изменений.

Хорошие данные

Плохие данные

Сообщение об ошибке. БД без изменений.

Хорошие данные

Иные хорошие данные

Новое значение сохранено в базе данных

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

И, наконец, обсудим удаление. Главное, что тут нужно проверить – удаление значения и в интерфейсе, и в базе данных. Однако как и в случаях с чтением и обновлением, нужно убедиться, что плохие данные можно удалить. К примеру, Если в имени 41 символ (нарушается правило "не более 40 символов), нужно убедиться, что его можно удалить через интерфейс.

Возможно, вы думаете, где найти "плохие" данные для тестирования. Их, конечно, можно обнаружить в существующих записях, но самый простой способ – добавить их самостоятельно! Поэтому так важно знать нужный язык запросов – например, SQL – к вашей базе данных.

Если вы размышляете, почему тестирование плохих данных так важно, приведу пример. Один раз я тестировала контактную информацию. В базе данных было несколько неправильно отформатированных телефонных номеров. Когда я пыталась обновить контактную информацию для этого человека, то получала сообщение, что это невозможно, так как присутствуют невалидные данные. Это происходило, даже если я пыталась отредактировать эти самые неправильные номера телефонов! Убедитесь, что вы проверяете такие сценарии – ваш пользователь скажет вам спасибо!