Learn-json-web-tokens: Тестирование API, использующего JWT

Что ж, у меня есть несколько предложений, которые могут сработать:

1. Настройте _test_ клиент в своей системе и жестко закодируйте токен в тестах. Продолжайте аутентификацию.
2. При запуске тестов убедитесь, что аутентификация отключена. Я предполагаю, что есть разные способы сделать это. Например, в Hapi вы можете оставить схему аутентификации по умолчанию и установить ее только тогда, когда сервер действительно работает (но не при выполнении тестов).
3. Создайте макет стека, чтобы вы только модульное тестирование логики контроллера, не выполняя запросов через систему. Однако это может быть невозможно в некоторых фреймворках.

Я работаю над некоторыми системами, где мы выбрали (1). Тогда тесты будут больше похожи на интеграционные, а не на модульные тесты, потому что они проходят через стек. С другой стороны, нет разницы между тестовой и производственной средой.

Вы можете установить NODE_ENV=test при запуске тестов (параметр fx. -e в лабораторной работе ), если вы хотите определить среду в коде. Однако вы должны знать, что тестовая и производственная среда не слишком сильно отличаются, иначе вы на самом деле не тестируете производственную среду.

@ rhewitt22 мы предпочитаем подход, описанный @walling
(где тесты больше напоминают «интеграционные», а не «модульные» тесты)
именно по этой причине. Все, что вы издеваетесь, является «_fake_», и поэтому вы не узнаете, работает что-то «_real_» или нет (_ поэтому ошибки более вероятны_).

Мы унаследовали (_ больших_) проектов, в которых люди _ забывают_ обновлять моки при изменении методов, и в результате тесты не отражают _реальность_; _ кошмар для отладки _!

Всегда спрашивайте себя: «_ ( Почему ) нам нужно издеваться над этим ? _»

Если вы издеваетесь над чем-то, потому что это находится вне вашего контроля, например, сторонней службой или сетевым устройством,
это имеет смысл. Но если вы издеваетесь над своим _own стеком _, вы должны учитывать, что можете чрезмерно усложнять вещи ...

Подсказка в вашем _вопросе_ находится в термине « _API _», это означает, что вы тестируете не «модуль», а скорее (API) «_ конечную точку _».

Попадите в конечную точку, и если вы получите 401, значит, вам нужно _аутентифицировать_! (_Хорошие новости! Ваше приложение работает, как ожидалось! _)

Вот _работающий пример _ теста, который _ делает именно то, что вам нужно _:
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

Тогда я бы рекомендовал прочитать:

• Когда издеваться: https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• Моки - это не заглушки: http://martinfowler.com/articles/mocksArentStubs.html
• Тестирование микросервисов: http://martinfowler.com/articles/microservice-testing/
• Когда я должен издеваться? http://stackoverflow.com/questions/38181/when-should-i-mock

tl; dr

Если ваш _собственный_ код слишком сложен и вы чувствуете, что _необходимо_ высмеивать его, _вначале упростите свой код _ !!

Кроме того, мы написали наш плагин hapi-auth-jwt2, чтобы другие могли положиться на наше тестирование. И выпустил пример _linear scaleable_, поддерживаемый Redis: https://github.com/dwyl/hapi-auth-jwt2-example, чтобы люди могли копировать и вставлять (_tested_) код! :подмигивание:

_Мы_ только имитируем, когда наши тесты «кажутся слишком медленными _», в противном случае мы _всегда_ тренируем столько стека, сколько _возможно_ на каждом проходе теста (при этом ограничивая зависимости только _существенными_).

Если элемент функциональности вашего приложения требует аутентификации, почему бы вам не использовать это как _возможность_ для _использования_ ваших методов аутентификации / проверки? В конечном счете, знание того, насколько _производительна_ ваша аутентификация, будет _хорошо_ для вашего приложения, потому что аутентификация / проверка - одно из самых узких мест в вашем стеке! (т.е. _every_ GET / POST / PUT / DELETE _request_ должен пройти аутентификацию / проверку, поэтому это не должно занять более пары миллисекунд ... больше, чем это, и ваше приложение _ не будет масштабироваться_!)

Помните: не _assume ничего _ и сделать свой собственный ум о том , как это имеет смысл для тестирования приложения. Если бы существовал «правильный способ» проведения тестирования, все университеты преподавали бы его ... его нет. «Лучший способ» - это подход «_pragmatic_»; делайте то, что имеет смысл для _вашего_ проекта.

Надеюсь, это поможет. если нет, сообщите нам, где вы застряли! : +1:

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

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

Если это поможет, в моем текущем проекте используется SailsJS v11.0. У меня есть тестовый файл начальной загрузки, который запускает мой сервер и создает / заполняет базу данных в памяти с приборами. Может быть, это подходящее место для создания тестового клиента?

Еще раз спасибо - замечательно видеть людей, которые так готовы делиться своими знаниями.

@ rhewitt22 , ну, в моем случае тестовый клиент был так же прост, как создание токена JWT с неограниченным сроком действия, подписанного с правильной полезной нагрузкой и секретным ключом. Может быть, это поможет.

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

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

@ограждающие конструкции

Спасибо за совет!

Я просто пошел дальше и создал поддельного пользователя, пропустив поток oAuth, в своих тестах и ​​предоставил им тот же JWT (с истечением срока действия), который я использую в производстве. Все тесты проходят, и я очень доволен кемпером.

: smile:: smile:: smile:

Я полагаю, что пока я работаю над своим приложением и смотрю на сервер разработки, я буду следить за тем, чтобы часть oAuth работала должным образом.