对于上下文，我们有一个 Angular + Nx monorepo，目前只有一个主要的 app，但我们计划很快将其拆分为几个独立的微前端。

我们目前只有一个主要模块，util-models，它包含所有描述所有 API 交互的接口(interface)，以及所有 我们在测试中用来模拟数据的 stub 。

现在假设我有一个库 my-feature，其中包含一些我想要构建和部署的功能(作为延迟加载的路由或作为主包的一部分)。这个库已经依赖于 util-models，因为它处理一些标准化数据，但我们还有一个单独的 my-model.model.ts 文件，它只描述接口(interface)特定于此功能。

一些视觉表现:

\my-feature
  \lib
    - my-models.model.ts
    - my-component.component.ts
    - my-component.component.spec.ts

\util-models
  \lib
    - shared-model.model.ts
    \test
      - shared-model.stub.ts

所以问题是，我应该将包含所有库特定 stub 的 my-models.stub.ts 文件放在哪里？

1.第一个明显的答案似乎是“将特定于库的代码放入库中”。但这是否意味着我所有的库实际上应该旨在为所有 stub 或特定于它们的测试实用程序创建一个单独的 test 目录？这是否也适用于模型(甚至不是可编译代码，只是接口(interface))？这不会降低这些本应帮助开发人员的工具的可发现性，以防将来其他一些库实际上也在处理相同的数据结构吗？

此外，此代码是否会与常规 .spec.ts 文件一起从产品构建中自动删除？仅仅不将其导入到 module 中就足够了吗？

2。另一种选择是将它放在已经存在的 util-models 库中，my-feature 可能会继续依赖它，但显然我担心这只会减少它长期分开。另一方面，如果这只是测试永远不会投入生产的代码，那么也许这实际上很好，或者出于某种原因甚至是可取的？

我最感兴趣的是这两个选项可能会如何影响构建/测试构建时间、tree shaking、延迟加载和迁移到微前端等事情。如果有任何提示，我将不胜感激!

最佳答案

我还没有找到任何官方文档来解决这个问题，但是在花更多时间使用 Nx 之后，尤其是在了解更多关于 DDD(领域驱动开发)之后，我变得更加直觉.

我目前的直觉是，实际上不相关的库之间代码的“可发现性”不是一个特性，而是一个问题。所有代码都应该属于它自己的特定领域，而不是集中在某个大型通用库中——它只是接口(interface)或测试代码都没有关系。

每个“共享”库，如果我们允许它存在于我们的依赖树中，则必须有一个至多特定于一个域的目的。

因此，我现在对以下决定充满信心:

1. 我们的目标应该是解散中央 util-models 库。描述 API 响应的模型都可以分配给更具体的域。
2. 如果我们想在特征库之间重用模型，因为我们确定它们实际上确实属于同一个业务领域，那么我们将创建一个单独的实用程序库，仅用于共享那些特定的此特定领域的模型。
3. 从逻辑上讲，我们应该开始在任何拥有模型的库中包含单独的 test 目录，以便在我们想要测试我们的组件/服务/等时准备好模型 stub 。在那个图书馆。

关于angular - 在 Nx + Angular monorepo 架构中，我应该在哪里放置特定于一个库的测试助手？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/71785098/