Haskell语言服务器测试套件中避免使用expectFail的最佳实践

在Haskell语言服务器(HLS)项目的测试开发中，测试套件中广泛使用了expectFail函数来标记预期会失败的测试用例。然而，这种做法存在明显的技术缺陷，值得我们深入探讨并寻找更优的解决方案。

expectFail的问题本质

expectFail函数来自tasty-expected-failure测试框架，它的核心行为是将任何测试失败都视为成功。这种设计虽然简单直接，但却隐藏了测试失败的具体原因，导致我们无法准确判断：

1. 测试是否因为预期的原因失败
2. 测试是否因为其他意外原因失败
3. 测试失败的具体表现是否符合预期

这种信息丢失使得测试的价值大打折扣，长期来看会降低测试套件的可靠性。

更优的替代方案

经过项目维护者的讨论，我们确定了以下几种更优的实践方式：

1. 精确断言替代模糊预期

对于已知会失败的测试，我们应该使用精确的断言来验证具体的失败表现，而不是简单地标记为"预期失败"。例如：

-- 不推荐
testCase "某个测试" $ expectFail $ do
  someTestFunction

-- 推荐
testCase "某个测试" $ do
  result <- someTestFunction
  result @?= expectedValue
  -- 添加注释说明为什么这个结果是错误的

2. 使用专门的测试辅助函数

项目引入了专门的测试辅助函数来更好地表达测试意图：

hoverTestExpectFail :: TestName -> Position -> T.Text -> T.Text -> TestTree
hoverTestExpectFail name pos _ideal expected = 
  hoverTest name pos expected

更进一步，可以使用类型系统来增强表达力：

data ExpectBroken a where
  IdealBehavior :: a -> ExpectBroken a
  CurrentBehavior :: a -> ExpectBroken a

hoverTestExpectFail' :: TestName -> Position -> ExpectBroken BrokenIdeal -> ExpectBroken BrokenCurrent -> TestTree
hoverTestExpectFail' name pos _ expected = 
  hoverTest name pos (unCurrent expected)

这种设计使得测试用例更加清晰：

hoverTestExpectFail'
  "import"
  (Position 2 18)
  (IdealBehavior "Control.Monad**")  -- 理想行为：不应有额外换行
  (CurrentBehavior "Control.Monad\n\n")  -- 当前实际行为

3. 平台特定的测试禁用

对于确实需要在特定平台禁用的测试，expectFail仍然可以谨慎使用，但应该：

1. 明确注释说明禁用原因
2. 限制在特定平台条件
3. 定期检查这些测试是否仍然需要禁用

实施效果

通过这一改进，HLS测试套件获得了以下提升：

1. 测试意图更加明确，通过类型和函数名就能理解测试目的
2. 失败原因更加透明，可以准确知道测试为何失败
3. 便于追踪问题，当"当前错误行为"变为"理想行为"时，可以轻松识别
4. 测试文档化，通过注释和类型记录了预期的正确行为

总结

在Haskell语言服务器这样的重要开发工具中，测试质量直接关系到工具的可靠性。避免使用expectFail而改用更精确的测试表达方式，是提升测试套件质量的重要一步。这一实践不仅适用于HLS项目，对于任何重视测试质量的Haskell项目都有借鉴意义。

通过类型驱动的测试设计和精确的失败断言，我们可以构建更可靠、更易维护的测试套件，为项目的长期健康发展奠定坚实基础。