Я создаю API с помощью Servant, и, похоже, он работает очень хорошо. И в соответствии с лучшими практиками я пишу для него несколько тестов, следуя официальному руководству здесь. Но я борюсь с этой частью, используя Servant-Quickcheck.
Я пытаюсь использовать его, чтобы проверить, что мой API не выдает 500 ошибок, например:
quickCheckSpec :: Spec
quickCheckSpec = describe "QuickCheck global tests for public API -" $ do
it "API never gives 500 error" $
withServantServer publicAPI (return server) $ \burl ->
serverSatisfies publicAPI burl args (not500 <%> mempty)
но, к сожалению, тест не проходит. Для меня это сюрприз, учитывая, что я не сталкивался с такой ошибкой при тестировании вручную - но, эй, вот почему у нас есть автоматизированные тесты, верно? Особенно с такими инструментами, как QuickCheck, который, насколько я понимаю, должен сосредоточить внимание на «крайних случаях», которые вы, возможно, не подумаете тестировать вручную. (На самом деле я впервые использую QuickCheck в любой форме.)
Проблема, однако, в том, что неудачный тест бесполезен, если вы не знаете, на чем он не удался. И это то, о чем Servant-QuickCheck, похоже, не хочет мне говорить. Единственный вывод, который я получаю относительно провала теста, таков:
API never gives 500 error FAILED [1]
Failures:
src\\Servant\\QuickCheck\\Internal\\QuickCheck.hs:146:11:
1) QuickCheck global tests for public API - API never gives 500 error
Nothing
To rerun use: --match "/QuickCheck global tests for public API -/API never gives 500 error/"
Randomized with seed 1712537046
Finished in 10.8513 seconds
4 examples, 1 failure
(Есть несколько выполненных ранее модульных тестов, которые все проходят - 10 секунд - это еще не все!)
Это довольно сбивает с толку, потому что, как вы можете видеть, нет ничего, что указывало бы на то, как произошел сбой. Поскольку он тестирует API и, насколько я понимаю, выбирает для тестирования допустимые маршруты случайным образом, он должен сообщить мне, на каком маршруте возникла ошибка 500. Но, как видите, там точно ничего нет.
(Я разрабатываю проект с помощью Stack, кстати, и чуть ниже выше написано Logs printed to console, поэтому я не верю, что мне не хватает каких-либо файлов журнала, закопанных где-то, которые могли бы меня просветить. Я не смог найти в моей папке .stack-work.)
Я даже изменил свой args так, чтобы в нем поле chatty было установлено на True, но я все еще получаю только указанное выше.
Единственная подсказка, которую я получаю, которая не связана с QuickCheck, заключается в том, что мой API использует Persistent и регистрирует запросы к базе данных на терминале, поэтому я могу видеть запущенные запросы, которые я, в свою очередь, могу связать с маршрутом. . Однако я не особо доверяю этому, потому что маршрут, выполняющий показанный запрос, определенно работает в ручных тестах. (И это не всегда один и тот же запрос, когда он терпит неудачу.) Есть также несколько простых маршрутов, которые не запрашивают базу данных, поэтому сбой не обязательно связан с последним напечатанным запросом к базе данных (хотя, разумеется, я Я проверил и эти маршруты вручную, и они в порядке).
Я даже задавался вопросом, не может ли проблема быть в том, что QuickCheck поражает мой локальный сервер столько раз подряд, что он просто не может справиться и выдает ошибки, но в этом случае я ожидал бы, что это будет распространенная проблема, отмеченная на в учебнике. (И вывод журнала базы данных предполагает, что на самом деле он всегда дает сбой при самом первом "попадании".)
В любом случае, это всего лишь предположение, и я понимаю, что мне нужно выяснить, почему мой API может не пройти тесты, учитывая, что я не считал нужным делиться какими-либо подробностями о моем реальном API.
На самом деле я спрашиваю: почему мне не говорят, какие маршруты были протестированы, а какие прошли / не прошли, чтобы я, по крайней мере, точно знал, какие маршруты следует исследовать? И есть ли способ заставить Servant-Quickcheck показать мне эту информацию?
Мы будем очень благодарны за любой ответ на этот вопрос.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: я пробовал использовать предложение @ MarkusBarthlen ниже, но оно не дало мне дополнительной информации. Тем не менее, он указал на то, что Nothing, который вы видите в моем выводе на консоль, вероятно, каким-то образом является ключевым для этого, потому что в примере Маркуса он получает значение Just, содержащее информацию о запросе. Взглянув на строку 146 , исходный файл, указанный в сообщении об ошибке, явно x там, очевидно, является значением Maybe. Но я не могу понять, что это за тип на самом деле и какое значение имеет то, что он Nothing в моем случае. К сожалению, код выходит за рамки моего собственного опыта / способностей в Haskell - я вижу, что x считывается из MVar, который каким-то образом заполняется результатом теста, но, как я уже сказал, я не могу разобраться в деталях. Но мне действительно нужно знать не только то, почему мой тест не проходит, но и почему это конкретное значение x равно Nothing для меня и что это означает с точки зрения теста. Я был бы очень признателен за ответ, который объясняет это так, как я могу понять.
