我使用Test.Hspec.Wai.JSON
来检查api端点的返回值。我注意到,每当我创建一个值为0.0
的json时,当测试运行时,它将其转换为0
(Int),如果api返回0.0
,则测试失败。
let j = [json|{"test":0.0}|]
request "GET" "some_url" [("Content-Type", "application/json")] ""
`shouldRespondWith` j {matchStatus = 200}
body mismatch:
expected: {"test":0} ---> this is the issue (0.0 has become 0)
but got: {"test":0.0}
我在Haskell中没有那么高级,无法找出库代码中发生这种情况的地方。我看了Test.Hspec.Wai.JSON
的源代码,它似乎依赖于Aeson.QQ
,所以不确定问题的来源。这是Test.Hspec.Wai.JSON源代码,这是Aeson。
因此,我的工作是编写一个FromJSON
实例来解析整个响应并检查填写的记录。这有点乏味。
有什么建议,在库代码是什么导致这个?如何解决这个问题?
谢谢,
嫌疑人似乎是Data.Aeson.QQ
的这一行:
toExp (JsonNumber n) = [|Number (fromRational $(return $ LitE $ RationalL (toRational n)))|]
它将数字转换为Rational
,转换为Haskell表达式,然后得到结果表达式,然后将其转换回Number
。这最终丢弃了它是0.0
而不是0
的事实。
这通常不会是一个问题,因为Aeson正确地定义了==
,使具有相等值的Number
s相等。这成为Test.Hspec.Wai.JSON
的一个实际问题;它的工作方式是将对象编码回ByteString
,并期望它与它完全匹配。
虽然Data.Aeson.QQ
是你的问题的根本原因,我不会指责它。相反,Test.Hspec.Wai.JSON
不应该序列化JSON对象并期望它们的表示是等效的。相反,它应该对实际响应进行反序列化,并比较解码后的对象是否相等。(毕竟,浮点/整型并不是唯一可能的问题。它也无法处理重新排序的对象键。)我不熟悉Hspec,所以我不确定你是如何做到的。