是否有任何Haskell土地相当于Ruby-land的Bundler等。 al，如果没有，如何设计一个如此结构的项目？
读者注意 ：请耐心等待。 我保证会有一个问题。
我有一个问题要解决，并对自己思考“哦，我会用Ruby做的。”
$ bundle gem problemsolver create problemsolver/Gemfile create problemsolver/Rakefile create problemsolver/.gitignore create problemsolver/problemsolver.gemspec create problemsolver/lib/problemsolver.rb create problemsolver/lib/problemsolver/version.rb Initializating git repo in /tmp/harang/problemsolver 删除在s.add_development_dependency "rspec" problemsolver/problemsolver.gemspec对s.add_development_dependency "rspec"的评论，然后
$ bundle exec rspec --init The --configure option no longer needs any arguments, so true was ignored. create spec/spec_helper.rb create .rspec
新测试将进入spec/并且必须位于以_spec.rb结尾的文件中。 例如， spec/version_spec.rb
describe 'Problemsolver' do it 'should be at version 0.0.1' do Problemsolver::VERSION.should == '0.0.1' end end
要运行规范 – 忽略像守卫这样的代码更改运行者 – 这是微不足道的：
$ bundle exec rspec . Finished in 0.00021 seconds 1 example, 0 failures
你看不到它，但是信息很好地用彩色编码，以便快速“我搞砸了吗？” 扫描？ 对此非常好的事情：
- 安装速度很快，几乎没有脑子（尽管确定要调用哪些命令并非无足轻重）。
- 源代码树的标准化布局通过新的代码库缩短了熟悉时间，使协作更加简单，并且在选择您已经离开的项目时减少了停留时间。
- 对工具的严重依赖通过社区分配最佳实践，大致以新项目创建的速度进行。
添加覆盖工具，代码观察者，短信， 行为测试工具和其他工具并不困难。
如果有人认为“哦，我会在哈斯克尔做这件事”，这与情况形成鲜明对比。
$ mkdir problemsolver $ cd problemsolver/ $ cabal init Package name [default "problemsolver"]? Package version [default "0.1"]? 0.0.1 Please choose a license: 1) GPL 2) GPL-2 3) GPL-3 4) LGPL 5) LGPL-2.1 6) LGPL-3 * 7) BSD3 8) MIT 9) PublicDomain 10) AllRightsReserved 11) OtherLicense 12) Other (specify) Your choice [default "BSD3"]? Author name? Brian L. Troutwine Maintainer email [default "brian@troutwine.us"]? Project homepage/repo URL? Project synopsis? Solves a problem. Project category: 1) Codec 2) Concurrency 3) Control 4) Data 5) Database 6) Development 7) Distribution 8) Game 9) Graphics 10) Language 11) Math 12) Network 13) Sound 14) System 15) Testing 16) Text 17) Web 18) Other (specify) Your choice? ProblemSolver ProblemSolver is not a valid choice. Your choice? 18 Please specify? ProblemSolver What does the package build: 1) Library 2) Executable Your choice? 2 Generating LICENSE... Generating Setup.hs... Generating y.cabal... You may want to edit the .cabal file and add a Description field.
“好极了，”你想，“我太过于沮丧，我敢打赌所有最新的Haskell软件开发最佳实践都在我的磁盘上等待。”
$ ls LICENSE problemsolver.cabal Setup.hs
请允许我总结一下我的感受:(
生成的cabal文件甚至没有指定Main ，更不用说设置基本项目的说明了。 还是，好吧。 如果你稍微试图找到正确的搜索关键字，你将落在如何写一个Haskell程序 ，这是好的，除了：
- 所有Haq源代码都被抛入根目录。
- Haq的测试代码仅在
Test.hs，只有Test.hs，并且无法通过拆分文件测试继续项目。 - 所有这些都必须为每个新项目手动编写或复制。
检查真实世界Haskell的第11章，你会发现它甚至没有提到阴谋和裙子完全是项目布局的问题。 Don Stewart 在这里提到的所有资源都没有在上述任何一个中得到解决，我将注意到，Stewart先生没有解释如何使用任何引用的工具。
请注意， Haskell测试工作流程中接受的答案引用了一个项目，该项目已经充分展开，因此不是一个好的答案，但确实说
由于阴谋测试尚不存在 – 我们有一名学生正在为今年夏天的代码工作！ – 我们拥有的最佳机制是使用cabal的用户钩子机制。
嘿，好的，cabal文档！ 适当的部分确实有例子，但是它们设计得非常好，但是不要让人觉得每个人都是自己的，祝你好运。
当然，总是测试框架看起来很好但是它的示例代码不提供超出wiki中所见的任何东西，并且在我的程序复杂性增长的情况下，我是不可扩展的挂钩开发将测试划分为可管理模块的方法。 我甚至不确定HTF会发生什么，并同意沃尔科夫先生的评估。
Jelvis先生对链接的HTF问题的评论对我特别感兴趣：Haskell工具链非常糟糕地受到小决策的暴政。 我实际上无法完成手头的任务 – 在Haskell中解决我的问题 – 因为我正处于让我的环境恰到好处的问题上。 为什么这很糟糕：
- 这是浪费精力。 除非我正在编写一个测试工具，否则我将非常非常关心我的测试是如何被填充的，只是从哪里开始 。
- 这很难学。 似乎没有单一的资源来建立一个带有测试的项目，而且确实存在的各种来源是多种多样的，以至于无益。
- 重现很难。 有这么多动人的作品要安排我每次都必须采用不同的方式。
- 作为必然结果，它是特殊的。 这意味着很难合作并获得hibernate项目。
这只是简单的臭味。
也许我错了。 是否存在一些宣传不佳的工具或密切开发的工具，以便在Haskell空间中执行与Bundler + Rspec类似的操作？ 如果没有，那么现在的Haskell测试中是否有一个广告宣传的典型例子，斯图尔特先生所引用的所有好东西都在其中？ 该项目创建或演示：
- 按惯例和工具应该以明确定义的方式将测试代码与应用程序代码分开（在Ruby-land中，Rspec测试符合
spec/，特色中的Cucumberfeatures/）， - 不应该要求最终用户编译和安装测试依赖项
- 应该易于重复，最好不超过10分钟
- 应该标准化或有标准化的希望。
我认为Haskell-land中没有这样的东西我错了吗？
编辑0：请注意，Ruby语言的社区不是唯一适用的比较。 Paul R.在确定配置的强大电流方面是正确的。 其他语言以其他方式解决了实现可扩展项目结构的问题：
- C ::这种语言令人尊敬，而且记录完备，以至于您无法确定采用哪种记录良好的方法。 没有这样的工具。
- Java ::基于约定的配置：您在编译器级别绑定它。 许多工具和很好的记录。
- Scala ::强大的工具支持。
- Erlang ::如果您知道自己在寻找什么，那就是一个很好的文件。 如果您正在使用钢筋或以其他方式瞄准OTP，可以说是超出惯例的配置。
Paul R.使用自定义模板的解决方案非常有用，如果像C一样，有足够的文档来编译这样的东西。 这仍然会遇到我试图在post中明确指出的问题，但它是可行的。 Haskell的最佳产品 – 我所知道的 – 是“如何编写一个Haskell程序”，但不足以相当于用手电筒和一瓶水将一个孤独的童子军扔掉在树林里。
此外，是的，静态类型很棒并且确实解决了许多本来需要进行显式测试的问题。 如果它们是最终解决方案，或者甚至是足够的解决方案，那么快照框架就不会经过如此彻底的测试。 （可以说是“复制快照核心。”是我的问题的答案。）
目前没有一种方法可以设置测试套件。 希望人们能够对开箱即用的cabal test标准化。 实际上， HUnit和HUnit都提供了Haskell平台，因此设置测试不需要下载任何额外的依赖项。
你是正确的，旧的接受答案不提供有关cabal test信息。 我编辑了它，现在确实如此！ 您也可能是正确的，Haskell维基上的链接页面（也是在cabal test可用之前编写）不提供有关当前测试最佳实践的信息。 这是一个维基，我鼓励人们编辑它！ 但请注意，该页面提供了指向另一个页面的链接， 该页面描述了如何构建更复杂的Haskell项目。
tldr; 使用cabal test 。 我喜欢test-framework ，如果您愿意，可以将其与cabal test集成。 很抱歉， cabal test是一种新的，并不是我们拥有的所有资源（通常是社区可编辑的）已经更新以指向它并描述如何使用它。 更新大量资源和创建教程是社区的工作。 我们应该做得更好，在过去几年中推广许多引入Haskell生态系统的新工具。
这里有很多要点。 首先，将配置约定与显式配置进行比较。 在ruby的土地上，前者往往是首选。 根据我的经验，尽管它可以很好地用于5分钟的网络直播和快速实验，但它在你的真实项目中的价值要低得多（超过5分钟） ）因为初始时间很快就会摊销。 此外，工具提供配置设施的原因有很多：有许多不同的需求和用途。 所以我对你的cabal-init问题的建议是：制作你自己的模板文件。 为您需要的一切提供存根，并提供很好的评论，并在您需要时使用它。
关于测试，ruby和哈斯克尔之间的景观很平静。 在ruby中，人们可以写foo do { oh dear I am typing nonsense here }并且除了实际运行代码之外别无他法。 因此绝对需要自动化测试。 然而，在haskell的土地上，你的代码有一个很好的静态分析，加上一个非常理智的范例（纯粹的function非严格），经过多年的使用，我仍然感到惊讶，很难写出废话而不是立即被编译器捕获。 我也在工作中使用ruby，实际上，我的90％的测试都是穷人手册“静态检查”。
仍然存在错误设计或角落错误的空间，这就是快速检查存在的原因。 它会自动（是的，真的自动）找到角落错误并帮助您找到很多设计错误。 如果需要手动检查，您仍然可以使用现有软件包之一编写unit testing。
所以我的结论是：如果你在哈斯克尔地上遮住ruby灯，不要惊讶地发现到处都是阴影。 这里的情况非常不同，需要经验才能获得力量。 这并不意味着一切都很完美，实际上改进工具链是一个普遍表达的愿望。 只是你提出的要点并不是真的有问题，而且真的不值得你选择一些词汇。 先试试，判断:)