Ответ теста Spray.io не соответствует фактическому результату

Question

Я пытаюсь настроить некоторые тесты для API, сделанные коллегой с использованием spray.io, и я сталкиваюсь с каким-то странным поведением. Когда запрос приводит к ошибке по любой причине, мы хотим, чтобы вернуть значение JSON вдоль линий:

{"status":false,"message":"useful message here"} 

Это происходит только штраф в самом браузере. Я перешел к необработанному маршруту в веб-браузере, и я получил желаемое значение JSON. Итак, я хочу проверить это. Теперь, поскольку я новичок в области spray.io, я начал с очень простого теста:

"leave GET requests to root path unhandled" in { 
    Get() ~> myRoute ~> check { 
    handled must beFalse 
    } 
} 

Все прошло отлично, никаких проблем. Так как это мой первый раз играл с spray.io, я смотрел на некоторых из образцов тестов для проверки ложных маршрутов, и завернутых myRoute с sealRoute(), чтобы я мог проверить реакцию без непройденных тестов:

"leave GET requests to root path unhandled" in { 
    Get() ~> sealRoute(myRoute) ~> check { 
    handled must beTrue 
    } 
} 

Это также отлично работает , Итак, я решил просто убедиться, что текст ответа был годный к употреблению с этим, прежде чем я пошел в проблему разбора JSON и проверки отдельных значений:

"leave GET requests to root path unhandled" in { 
    Get() ~> sealRoute(myRoute) ~> check { 
    responseAs[String] contains "false" 
    } 
} 

Это не удается. Для того, чтобы исследовать, я бросил простую строку кода для входа фактического значения responseAs[String] в файл, и я получил это:

The requested resource could not be found. 

Может кто-нибудь сказать мне, что я делаю неправильно? Я имею в виду, что один из следующих происходит:

• responseAs[String] делает больше, чем принимать точный ответ и дает его мне, применяя некоторый тип фильтра по пути
• сама структура не полностью оценить запрос, а сделать макет объекта для испытания рамки для оценки, и, следовательно, не выполняя желаемый «ошибки поворота к JSon» метода, что мой коллега уже реализован

Я попытался найти Google и переполнение стека специально для подобных проблем, но я либо не вставляю правильные запросы, или большинство других людей довольны сообщениями об ошибках по умолчанию и не пытаются их проверить, кроме проверки handled must beFalse.

Edit - это соответствующая часть RejectionHandler:

case MissingQueryParamRejection(paramName) :: _=> 
    respondWithMediaType(`application/json`) { 
    complete(BadRequest, toJson(Map("status" -> false, "message" -> s"Missing parameter $paramName, request denied"))) 
    } 

Answer 1

Итак, с пониманием отсюда и коллеги, проблема была обнаружена:

В принципе, обычай RejectionHandler был определен в пределах нашего пользовательского объекта Actor, и он не попадал в рамки тестов. Чтобы решить эту проблему, были предприняты следующие шаги:

• покрутил определение обычая RejectionHandler в свой собственный объект в отдельном файле (как это должен был сделать свой собственный импорт, он вызывает «Неустранимая цикл разрешающую import ")
• Импортировал этот новый объект как в исходный файл, так и в тестовую спецификацию.

(забавный факт - http://spray.io/documentation/1.2.2/spray-routing/key-concepts/rejections/#rejectionhandler кажется, чтобы продемонстрировать RejectionHandler как объект верхнего уровня, но вы не можете иметь неявные Vals верхнего уровня в Scala, следовательно, потребность в объекте)