Какой оптимальный (время написания тестов/эффективность) вариант тестирования веб-апи?
Собираюсь реализовать простенький менеджер задач на nodejs с возможностью назначения исполнителей.
Как почти в каждом проекте начал с аутентификации, далее будут сообщения между пользователями, редактирование профиля пользователем, создание проекта, добавление участников, создание задач в проекте, назначение исполнителей и выполнение задач.
Решил конечно же для поддержания лучшей практики писать тесты для своего приложения. Для сего дела выбрал mocha + should + supertest, ну в принципе мой вопрос не об этом. Почитал, посмотрел о тестировании и решил, что юнит-тестирование будет слишком дорогим удовольствие в плане времени, а вот тестирование по конкретным урл-запросам с отправкой верных и неверных данных будет оптимальным вариантом.
К примеру первый тест у меня для регистрации. Вот такие данные отправляются и все запросы, кроме последнего возвращают ошибки:
[
{},
{email: 'tyrty'},
{email: 'tyrty"jskjk'},
{email: 'tyrty@jskjk'},
{email: 'tyrty@jsk.jk'},
{email: 'tyrty@jsk.jk', password: '123'},
{email: 'tyrty@jsk.jk', password: '123".,sk'},
{email: 'tyrty@jsk.jk', password: '1228uskj'},
{email: 'tyrty@jsk.jk', password: '1228uskj', password_confirm: '123'},
{email: 'tyrty@jsk.jk', password: '1228uskj', password_confirm: '1228uskj'},
]
И так для каждой функции (которая соответственно находится на отдельном маршруте)
Я подозреваю, что этот вид тестирования называется функциональным. Так как тестируются отдельные функции программы.
Но далее, например идет тест аутентификации и там получается я использую этот же tyrty@jsk.jk и пароль 1228uskj для теста правильного запроса. А пишут, что надо чтобы тесты были независимыми друг от друга. А если они будут независимы, то откуда мне получить правильный логин и пароль (в базу лезть что ли каким-то левым методом)?
Далее пойдут более сложный функционал создания дополнительных пользователей, добавление их к проекту, назначение им ролей с определенными правами, и тд, то есть надо будет проверить всевозможные варианты, чтоб нигде пользователю без права на то или иное действие это действие было недоступно. То есть тест будет идти как бы по нарастающей. В конце теста или при его крахе из бд будет удаляться тестовая информация.
Динамически создавать необходимое окружение для теста см. faker
Можно написать пару "помощников" для этого дела, тк с юзерами часто много манипуляций в тестах
тестирование регистрации и аутентификации никак с точки зрения теста друг с другом не связаны.
в тестах регистрации вы хотите убедиться в том что если ввести невалидные данные то система даст отрицательный ответ. и если данные валидные то система ответит положительно.
при логине вы хотите убедиться в том что если послать системе данные не существующего аккаунта система даст отрицательный ответ. если дать данные заблокированного аккаунта (ну например есть у вас такая категория), система ответит правильным сообщением. и, если пользователь существует и не заблокирован система ответит положительно. Естественно чтобы провести эти тесты, вам понадобится один валидный аккаунт в базе, чтобы система могла ответить положительно, и данные одного не существующего аккаунта, и одного заблокированного аккаунта. Если логин в систему не работает, ваши тесты логина обнаружат баг.
Чтобы добится независимости от такого возможного бага, вы при тестировании запросов с залогиненым пользователем настраиваете систему перед тестом таким образом чтобы она не учитывала информацию по логину.
Давайте разберем на примере: представьте вы тестируете инсталляцию системы пожарной безопасности в секретной лаборатории. Доступ в помещение только по электронной карте. Внутри помещения есть кнопка включения сигнализации, при срабатывании которой должны закрыться все окна в помещении и должен быть разблокирован замок двери.
Вы тестируете замок двери отдельно. А для теста сигнализации и срабатывания оконной механики вы отключаете систему входа по карточке, и делаете его свободным. потому что идентификация при входе в помещение не является предметом теста для системы сигнализации (закрывание окон). В этой точке достигается независимость тестов.
Но отключив замок двери для теста, вы не сможете убедиться в том что замок открывается при срабатывании сигнализации (второе условие) . Вам придется непосредственно перед проверкой снова включить дверной замок.
Однако в случае если при тестировании входа выяснится что дверной замок не работает, то включить дверной замок для теста не получится, и второй тест скажет что мол замок двери открылся, все хорошо, однако на самом деле замок был все время открыт, потому что неработал. (т.н. false positive)
Чтобы добится независимости от такого возможного бага, вы при тестировании запросов с залогиненым пользователем настраиваете систему перед тестом таким образом чтобы она не учитывала информацию по логину.
Дело в том, что сервер абсолютно не знает, тестирование сейчас проходит или реальный пользователь проверяет все фичи приложения со скоростью 25 запросов в секунду :) Условия самые так сказать боевые. Я конечно в тестировании пока полный чайник, но из опыта разработки могу сказать, что иногда случаются разнообразные казусы от различия в окружениях (дев, прод и тест), поэтому хотел бы проводить тестирование сначала на локальном сервере, а затем сразу же после деплоя на production-сервере. Проект по сути предполагается небольшим, поэтому тест всех функций после его полной реализации, думаю, не превысит и минуты.
Ну а дальше, новую фичу запилил, может потребуется доработка каких-то общих компонентов. Тест прогнал, весь функционал проеврил сразу, не боясь о том, что на тест-окружении все было норм, а на проде что-то пойдет не так.
frontendo, если вы хотите тестировать как отреагирует код на задержку ответа сервера, или на неожиданный http код то и это можно протестировать. для этого вам нужно отправлять запросы не к живому серверу, а к моку сервера, который вы сможете настроить нужным для теста образом.
Alexej Simakov, простите за мою необразованность в вопросе тестирования. Но мне тест нужен для того, чтобы быть уверенным, что именно на боевом сервере в обычном режиме весь разработанный функционал работает нормально)
для тестов никто продакшен окружения не крутит, для этого специально тестовые окружения и придумали
а если логика поракшен окружения сильно отличается от тестового то возможно стоит пересмотреть архитектуру
либо проверять ручками
