Haskell: Как протестировать приложение Spock, которое использует wreq? - PullRequest
Новая
       34

Haskell: Как протестировать приложение Spock, которое использует wreq?

0 голосов
/ 26 августа 2018

Я написал очень простое приложение на Haskell, используя Spock и wreq .Я хочу написать несколько тестов, но я не уверен, как это сделать.

Все, что делает приложение, - это отправляет HTTP-запрос на другой сервер и переводит ответ JSON в удобное для человека сообщение.Вот код , если это поможет.Я хочу написать тест, который утверждает, что удобное для человека сообщение является правильным при заданном ответе JSON.

В Ruby я бы выбрал HTTP-клиента, в данном случае wreq, для управления ответом JSON.Я понимаю, но я не уверен, как и даже если это сделать в Хаскеле.

Из того, что я понял из своего исследования, это звучит так: переменные типа с ограниченным классом типа - это путь, который для меня выглядит как внедрение зависимости, но я 'Я не уверен, как это сделать в контексте Спока и Врека.

В руководстве по тестированию Спока описывается, как тестировать Спока на уровне IO Application, что звучит великолепно.Часть, в которой я не уверен, заключается в том, как «внедрить» фиктивный HTTP-клиент для контроля ответа JSON.

Любая помощь приветствуется!

1 Ответ

0 голосов
/ 27 августа 2018

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

Если мы используем cabal-install > 2.0(с помощью команд new- * ) другим возможным вариантом является использование сигнатуры модуля для переключения реализаций между набором тестов и конечным исполняемым приложением.Это решение также интенсивно использует функцию внутренних удобных библиотек Cabal.

Основная идея заключается в следующем: мы помещаем наше приложение Spock в его собственную библиотеку, но не делаем его зависимым от WREQ напрямую.Вместо этого мы объявляем в той же библиотеке сигнатуру Requests.hsig следующим образом: 

signature SomeSpockApp.Requests where

import           Data.Aeson (FromJSON)

data Token

doGET :: FromJSON a => String -> Token -> IO a

Она определяет высокоуровневый интерфейс для выполнения HTTP-запросов.Код в библиотеке импортирует эту подпись.Для остальной части кода в библиотеке SomeSpockApp.Requests - это просто еще один модуль.

Далее мы определим вспомогательную библиотеку, которая будет предоставлять фактический модуль SomeSpockApp.Requests (то же имя, что и у подписи, за исключением того, что сейчасэто hs файл).Он будет содержать «ложный» код.Конечно, определение doGET должно быть совместимо с подписью.

Мы также определяем другую вспомогательную библиотеку с другим модулем SomeSpockApp.Requests.Это должно зависеть от wreq и выполнять методы нашей подписи с использованием функций wreq.

В наборе тестов мы должны зависеть как от нашей библиотеки приложений Spock, так и от библиотеки mock.Имена сигнатуры и макета модуля реализации выстраиваются идеально, поэтому больше ничего делать не нужно.(Если имена не совпадают, мы можем использовать mixins раздел в файле cabal для переименования модуля).

В исполняемом приложении мы должны зависетькак в нашей библиотеке приложений Spock, так и в библиотеке использования wreq

...