Сообщений в теме: 4

[lingva]

Стоит задача автоматизировать некий бизнес-процесс: интеграционное сообщение должно прийти в систему, лечь в базу и отобразиться в web-интерфейсе.

Понятное дело, обязательно проверим в интерфейсе (в сравнении с тем, что было в сообщении), но стоит ли осуществлять тестирование на уровне БД и проверять там или это лишнее?

Вопрос в том, как корректнее проверить, чтоб ничего не упустить?

[wret]

Проверять в UI следует в любом случае, могу быть проблемы приведения типов данных, кодировки, форматирования, ...

 

Проверять ли в БД? Да, очень желательно, но немного зависит от контекста

Тут все может упереться в разработку класса работы с БД (трудозатраты). Если он уже существует и стоит всего лишь подставить верный запрос - проверяйте

Следующий пример - безопасность данных. Если в требованиях стоит хранения данных в зашифрованном виде, а при интеграции с сторонними системами это немаловажно (в случае чего могут утечь как ваш данные так и их), тестированием интерфейса это не проверить. Программист вполне может расшифровать данные при записи в БД для дальнейшей более удобной (для него) работы с ними, для быстроты отображения для конечных пользователях, ...

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

[lingva]

Проверять в UI следует в любом случае, могу быть проблемы приведения типов данных, кодировки, форматирования, ...

 

Проверять ли в БД? Да, очень желательно, но немного зависит от контекста

Тут все может упереться в разработку класса работы с БД (трудозатраты). Если он уже существует и стоит всего лишь подставить верный запрос - проверяйте

Следующий пример - безопасность данных. Если в требованиях стоит хранения данных в зашифрованном виде, а при интеграции с сторонними системами это немаловажно (в случае чего могут утечь как ваш данные так и их), тестированием интерфейса это не проверить. Программист вполне может расшифровать данные при записи в БД для дальнейшей более удобной (для него) работы с ними, для быстроты отображения для конечных пользователях, ...

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

Огромное спасибо за совет и оперативный отклик. Приму к сведению.

[Snap]

Зависит от требований 

[neman]

Я бы разбил это на две фичи (два теста):

1. При выполнении некоторых действий приходит сообщение.
2. Cообщение отображается в интерфейсе.

Проверять в БД лучше, если:

• Мы умеем писать в БД или умеем подменять сообщения от сервиса - тогда эти фичи мы можем проверить независимо друг от друга. Т.е. во втором тесте вместо реального получения сообщения мы его подменим своим и посмотрим, как оно отображается в интерфейсе.
• У нас есть разные наборы тестов для этих двух фич. Например, сообщение вызывается разными действиями, или у него есть параметры, которые отображаются одинаково. В этом случае быстрее сгенерировать много разных сообщений, проверить что в БД лежат верные значения, а во втором тесте посмотреть, что одно из сообщений корректно отображается в интерфейсе. Здесь мы исходим из предпосылки, что смотреть в БД - это быстрее и надежнее, чем в интерфейсе.
• В приходящем сообщении есть важные параметры, которые не отображаются в UI.

Проверять только в интерфейсе, если:

• Есть проблемы с обращением к БД или с данные лежат в тяжелом для парсинга формате.
• Приходит много системных параметров, которые мы не хотим тестировать, и которые нам тяжело замокать.
• Приходит всегда одно и тоже сообщение, которое полностью отображается в UI (проверка в БД здесь не лишняя, но если это трудоемко, то игра не стоит свеч).

Может быть я еще что-то упустил.

Бонус от разделения тестов на две группы - в случае падения мы сможем понять, что случилось - или к нам пришли неправильные данные, или правильные данные неправильно отобразились в UI.