gpt4 book ai didi

angular - 在 Nx + Angular monorepo 架构中,我应该在哪里放置特定于一个库的测试助手?

转载 作者:行者123 更新时间:2023-12-05 08:03:39 29 4
gpt4 key购买 nike

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

我们目前只有一个主要模块,util-models,它包含所有描述所有 API 交互的接口(interface),以及< em>所有 我们在测试中用来模拟数据的 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/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com