使用EUnit似乎有两种常用方法：
假设我只对测试特定模块的导出函数感兴趣，那么选择一种方法优于另一种方法是否有任何优势或惯例？
答案 0 :(得分：3)
tl; dr：您通常可以将它们放在源的底部而不会弄乱。交错总是很糟糕。编写如此多的测试，以及需要一个特殊的测试专用代码的地方，这意味着你错误地投入了时间。
在某些情况下，将其分解可缩短源文件并使其更易于导航。 OTOH，难以导航源通常是其他更深层次问题的标志。
我发现Dialyzer和用户是我真正的bug发现者，除了纯功能，零副作用代码之外，测试相对较少。在纯函数代码的情况下，测试是微不足道的 - 一旦检查了那种代码，它就是一个不错的选择，没有人必须重新访问它的年龄和年龄，如果有的话。在那些情况下，我通常会在最后包括测试，所以如果我们想回去再找到它们，我就不会失去它们。我有意识地进行重构，直到尽可能多的代码属于这种类型 - 不是每个人都同意这是值得的。
代码的毛茸茸的部分是副作用的部分，特别是如果你还没有完成与typer和Dialyzer的一些工作，以找到你自己犯下的最重要的攻击。现实世界中所有错误的唯一共同点就是它们已经通过了所有测试。我从来没有发现编写测试的努力与副作用代码中的bugginess之间存在任何关联。实际上，目前还没有办法正式测试演员模型协议，而且互动通常是剩下的错误所在，而不是隐藏在你已经仔细考虑的过程中。
从具体角度来看，请考虑一下：您是否愿意在某个系统上工作X个小时正确打字，或者X小时编写并运行测试？我的投票是打字。我并不是说测试不好，我说它在开发人员时间上很昂贵，并且在纯功能代码之外的实用性有限。对纯功能代码的测试具有明确可识别的限制，往往是微不足道的，并且很小，因此可以不显眼地驻留在它们适用的模块的底部。