💡Как я тестирую REST API огурцами. Часть 1
Разработчиков часто спрашивают как они тестируют REST API и многие начинают рассказывать истории про тесты покрывающие контроллеры.
Да, все верно! Все это делает тесты частью исходного кода и как правило они выполняются неотделимо от сборки программы,
а значит обеспечивают быструю и понятную доставку фидбека о потенциальной работоспособности приложения.
Другими словами, разработчики быстро узнают что пошло не так.
Но с другой стороны все это порождает ряд ограничений, когда в случае написания таких тестов часто приходится прибегать в мокам (англ. - mock) и стабам (англ. - stub), чтобы не вызывать реальные сервисы в угоду изолированно выполнения тестов свободных от внешних факторов и не препятствия сборке проекта в случае, когда код работоспособен, но downstream или thrird-party сервис недоступен по причинам не зависящих от нас.
К потенциальным ограничениями можно также отнести непонимание клиента о том, что реально тесты делают и какие-то именно бизнес-сценарии они покрывают.
А вот именно это клиент и хотел бы знать, верно?
Как раз тот случай, когда нам нужен E2E (end-to-end) сценарий, да еще такой чтобы нормальным человеко-понятным языком показал, что было выполнено и каков результат.
Для этого я предпочитаю использовать BDD (Behavior Driven Development) и реализовывать этот прием при помочи Cucumber и Gherkin Syntax.
Cucumber позволяет создавать, запускать, анализировать тесты, Gherkin Syntax - описывает тесты в простой человеко-понятной форме как:
"Client does call to endpoint for getting its profile information".
Самое крутое, что весь этот зоопарк поддерживает множество языков программирования, имеет множество интеграций с другими библиотеками и сервисами, а бизнес-сценарии может описывать простой человек.
Ну круто же, а!?
Больше информации можно получить по ссылке: https://cucumber.io/
В следующих частях, я расскажу вам как всё это было успешно реализовано на нескольких проектах
и как мне удалость получить множественные "Вау, то что надо!", "Теперь я знаю, что приложение умеет! Спасибо!", "Именно то, что мы так долго ждали!".
Макс Добрынин
@maksymdobrynin
Разработчиков часто спрашивают как они тестируют REST API и многие начинают рассказывать истории про тесты покрывающие контроллеры.
Да, все верно! Все это делает тесты частью исходного кода и как правило они выполняются неотделимо от сборки программы,
а значит обеспечивают быструю и понятную доставку фидбека о потенциальной работоспособности приложения.
Другими словами, разработчики быстро узнают что пошло не так.
Но с другой стороны все это порождает ряд ограничений, когда в случае написания таких тестов часто приходится прибегать в мокам (англ. - mock) и стабам (англ. - stub), чтобы не вызывать реальные сервисы в угоду изолированно выполнения тестов свободных от внешних факторов и не препятствия сборке проекта в случае, когда код работоспособен, но downstream или thrird-party сервис недоступен по причинам не зависящих от нас.
К потенциальным ограничениями можно также отнести непонимание клиента о том, что реально тесты делают и какие-то именно бизнес-сценарии они покрывают.
А вот именно это клиент и хотел бы знать, верно?
Как раз тот случай, когда нам нужен E2E (end-to-end) сценарий, да еще такой чтобы нормальным человеко-понятным языком показал, что было выполнено и каков результат.
Для этого я предпочитаю использовать BDD (Behavior Driven Development) и реализовывать этот прием при помочи Cucumber и Gherkin Syntax.
Cucumber позволяет создавать, запускать, анализировать тесты, Gherkin Syntax - описывает тесты в простой человеко-понятной форме как:
"Client does call to endpoint for getting its profile information".
Самое крутое, что весь этот зоопарк поддерживает множество языков программирования, имеет множество интеграций с другими библиотеками и сервисами, а бизнес-сценарии может описывать простой человек.
Ну круто же, а!?
Больше информации можно получить по ссылке: https://cucumber.io/
В следующих частях, я расскажу вам как всё это было успешно реализовано на нескольких проектах
и как мне удалость получить множественные "Вау, то что надо!", "Теперь я знаю, что приложение умеет! Спасибо!", "Именно то, что мы так долго ждали!".
Макс Добрынин
@maksymdobrynin