【发布时间】:2009-03-23 11:12:50
【问题描述】:
我使用了 ghci 调试器,但如果它与文本编辑器在某种程度上集成以简化设置断点的过程,我会更喜欢它。它可能不应该严格评估每个可见变量,但至少简化查看本地状态的过程。
我最近发现了跟踪功能,它允许从其他困难的地方进行调试打印输出。
【问题讨论】:
-
可能你已经看过了,仅供参考:haskell.org/haskellwiki/Debugging
我使用了 ghci 调试器,但如果它与文本编辑器在某种程度上集成以简化设置断点的过程,我会更喜欢它。它可能不应该严格评估每个可见变量,但至少简化查看本地状态的过程。
我最近发现了跟踪功能,它允许从其他困难的地方进行调试打印输出。
【问题讨论】:
调试 Haskell 代码的一个好方法是使用 QuickCheck 和 SmallCheck 编写和测试代数定律。有几个 Haskell 调试器,包括 Hat、Hood 和 Freya,但没有一个被认为足够有价值,值得长期维护。
使用 Haskell 时,您必须以不同的方式思考如何做事。 QuickCheck 页面上的 ICFP 论文有一些很好的示例可以帮助您入门。如果您想要一个真实的示例,xmonad 使用 QuickCheck 进行了广泛的调试。
【讨论】:
是的,GHCi 调试器的前端将是一件好事。也许我们会在下一次黑客马拉松期间完成一些事情。但是,与此同时:
另外,Haskell 非常适合使用 QuickCheck 进行自下而上的测试。即,单独测试您的组件,然后将它们放在一起。如果您的代码是纯代码,这通常可以正常工作。
【讨论】:
附带说明,请注意,Debug.trace 在调试多线程程序时不会成为您的朋友。
从长远来看,测试是必经之路。
【讨论】:
出于我自己的目的,我发现这是多种因素的结合。
从其他答案中可以看出,很多人喜欢QuickCheck。我发现很难为我的一些代码定义有意义的 QuickCheck 测试用例,因此通常更多地使用标准单元测试。话虽如此,在 Real World Haskell 的 Chapter 11 中有一个很好的使用 QuickCheck 的介绍。
如果您发现自己同时使用 QuickCheck 和 HUnit,您可能需要查看 test-framework。
【讨论】: