什么结构让项目一眼就能知道什么需要单元测试，什么不需要？

Question

我正在寻找一些构建项目的方法，以便我一眼就能知道哪些文件 require/should 有单元测试，哪些文件没有。

这就是我寻找这个的原因：假设我有一个结构，其中有各种模块。在添加业务逻辑时，我还为其添加了单元测试。有一个业务逻辑 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

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

What are some other ways to structure for this?

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

Is there an agreed upon best practice way to do this?

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

什么结构让项目一眼就能知道什么需要单元测试，什么不需要？

What are structures for a project to know at a glance what needs unit tests and what doesn't?

javascript

architecture

integration-testing

unit-testing

directory-structure