什么结构可以让项目一目了然地知道什么需要单元测试，什么不需要？

Question

我正在寻找一些构建项目的方法，以便一目了然地知道哪些文件需要/应该进行单元测试，哪些文件不需要。

这就是我寻找这个的原因：假设我有一个结构，其中包含各种模块。在添加业务逻辑时，我还为其添加了单元测试。有一个业务逻辑someFile.js 文件和一个随附的测试文件someFile.spec.js。我也有将我的业务逻辑单元组合在一起的集成层代码。对于这些，我认为我只想在集成测试中涵盖它们。由于集成测试可以跨越多个文件，我将把它们放在顶级文件夹中。现在的问题是，当我查看项目的鸟瞰图时，看起来我缺少对那些仅集成文件的测试，而实际上我已经决定要在集成中涵盖它们测试而不是单元测试。所以，这涉及到一些心理开销。

我目前正在尝试和评估如下结构来帮助解决这个问题。每个模块都有一个文件夹。每个模块文件夹都有一个集成文件夹，我知道其中的文件不需要单元测试。每个模块文件夹还有一个服务文件夹，我知道我需要在其中进行单元测试。有一个顶级测试文件夹，其中包含集成测试。

src
|__ fileSystem
    |__ integration
        |__ save.js
        |__ delete.js
    |__ index.js
|__ dataApi
    |__ integration
        |__ get.js
        |__ getAll.js
    |__ service
        |__ success.js
        |__ success.spec.js
        |__ error.js
        |__ error.spec.js
    |__ index.js
|__ calculate
    |__ service
        |__ add.js
        |__ add.spec.js
        |__ subtract.js
        |__ subtract.specjs
    |__ index.js
|__ utility
    |__ service
        |__ sort.js
        |__ sort.spec.js
        |__ unique.js
        |__ unique.spec.js
    |__ index.js
|__ test
    |__ edit
        |__ addNote.spec.ts
        |__ removeNote.spec.ts
|__ index.js

我可以尝试使用代码覆盖来做到这一点，但我仍然需要某种模式来区分集成代码和业务逻辑代码。

还有哪些其他的结构方式？是否有公认的最佳实践方法来做到这一点？如果不是在 JavaScript 中，其他语言是否有这方面的最佳实践结构？

Answer 1

没有灵丹妙药。这取决于你的要求。这就是为什么以下想法可能会被不同的人认为是好是坏：

还有哪些其他的结构方式？

• 平面层次结构：展开结构可能是开销。多个不同的缩进级别可以增加更多的噪音，然后它们有助于组织。也许最好使用统一命名并减少文件夹深度。 （如：.spec 表示测试。） (Meaningful names) 现代 IDE 确实使搜索有意义的名称或命名模式变得非常容易。 (.spec)
• 投影：您是希望所有测试都放在一起，还是应该在他们正在检查的逻辑旁边？要回答这个问题，您需要think about at which point in development you write your test code。
• 为什么知道您的测试是集成测试还是单元测试如此重要？如果没有特殊原因，可以考虑降噪合并。

是否有公认的最佳实践方法来做到这一点？

• 不，但有语言偏好。它们不是一成不变的。
• 您的项目结构未绑定您的测试策略和code coverage is not what makes your code bullet prove。