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

Несмотря на непривлекательное название, тестирование CRUD очень важно! CRUD – это аббревиатура для Create, Read, Update, Delete (создание, чтение, обновление, удаление). Как знает любой тестировщик, большая часть нашего тестирования включает эти операции. Сегодня мы обсудим наилучшие способы тестирования создания и чтения.

Самое важное, что нужно знать, тестируя CRUD: недостаточно полагаться на то, что вы видите в интерфейсе, чтобы убедиться, что значение поля было создано или изменено. Это связано с тем, что интерфейс может кэшировать значения для более эффективной загрузки в браузере. Для того, чтобы абсолютно точно удостовериться, что значение изменилось, нужно проверить базу данных, где оно хранится. В результате вы убеждаетесь, что значение задано в двух местах – в интерфейсе и в базе данных. Если вы занимаетесь тестированием API, то можете подтвердить это в трех местах, но тестирование API мы сейчас затрагивать не будем.

Тестирование операции создания

Это текстовое поле – форма добавления пользователя. Мы введем туда имя пользователя и нажмем на "Submit". Затем мы посмотрим на страницу Users нашего воображаемого приложения, и убедимся, что новый пользователь создан:

Вот и он! Теперь нам нужно запросить базу данных, чтобы проверить, правильно ли сохранилось значение. В нашей воображаемой базе это можно сделать запросом

SELECT * from Users

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

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

Тестирование операции чтения

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

Давайте посмотрим, как могут выглядеть плохие данные в базе

В нашем воображаемом приложении интерфейс имеет ограничения на поле имени. Это обязательное поле, в нем должно быть не менее двух символов, их должно быть не больше 40, и они должны быть или буквами, или дефисами/апострофами – прочие символы запрещены. Как можно видеть в таблице, у нас много плохих данных.

• У пользователя 2 не заполнено имя
• У пользователя 3 вместо имени пустая строка
• У пользователя 4 нарушено правило "минимум два символа"
• У пользователя 5 нарушено правило "не более 40 символов"
• У пользователя 6 нарушено правило "из спецсимволов разрешены только дефисы и апострофы".

Что должно произойти, если мы откроем список пользователей в нашем приложении? Это зависит от дизайнерского решения. Возможно, плохие данные будут отображаться, если не угрожают безопасности – как, скажем, имя пользователя 6, которое на самом деле – сохраненная XSS-атака. Неважно, каковы правила для отображения таких данных – нужно проверить, что они соблюдаются.

Возможно, вы говорите себе (или разработчик говорит вам), что отображение плохих данных – не проблема, потому что у нас будет хорошая валидация, которая не даст таким данным попасть в базу данных. Это, конечно, стандартная практика сейчас, но всегда будут ситуации, когда плохие данные таки просочатся в базу. Как-то раз я тестировала операцию PATCH, где можно было вставлять в запись номера телефонов. Я обнаружила, что при правильном формировании тела запроса валидация проводилась, но существовал граничный случай, когда тело PATCH было сформировано неверно и принималось без валидации. Любой разработчик, неправильно запрограммировавший операцию PATCH, мог в результате разрешить "плохим" телефонным номерам проникать в базу!

Хорошее правило тестирования операций создания и чтения – предполагать, что что угодно может пойти не по плану, и тестировать соответственно. Продолжим разговор об этом в следующий раз, тестируя операции обновления и удаления.

Обсудить в форуме