【问题标题】:Is completely mocking the back-end logic for the front-end reasonable?为前端完全嘲讽后端逻辑合理吗?
【发布时间】:2018-05-24 17:29:22
【问题描述】:

我的老板让我想办法在本地环境中将我们的前端应用程序与后端完全解除关联,目前我是我们后端软件和前端的唯一开发人员,所以使用 Docker 我可以模拟生产环境并分别处理两个项目(我们不在服务器端渲染),他的想法是模拟所有内容,所以理论上你不需要后端开发前端的软件。

我想到的两个(更合理的)解决方案是:

  1. 在前端模拟所有网络请求,这些函数将 运行而不是网络请求。 这种方法的问题在于它不是持久的,所有数据都是为每个请求随机生成的,并且在一个如此面向表单、表格和列表的系统中,我觉得获得你所期望的数据之后表单提交是必须的。 为了持久化数据,每个请求都必须经过某种数据存储(Mobx、Redux 等),即便如此,如果页面刷新,数据也会消失。
  2. 在 Docker 上与 Webpack 一起启动 express 服务器和 DB,并使用 db 播种器模拟生产服务器的请求和响应,这样前端是持久的。 显然,这种方法会产生大量工作,并且为了确保 express 服务器正确模仿原始后端软件,它也需要单元测试和模拟请求。

虽然模拟数据非常适合单元测试,但在我看来,这不像是在这么小的团队中做前端的方式,有没有一种我想不出或找不到的好方法来实现这一点?或者这是对不良脱钩策略的一种练习?

【问题讨论】:

  • 实际上,嘲笑的整个想法是相当可疑的。为什么要花时间在永远不会用于生产的配置中开发和测试软件?
  • @artem 他的想法是前端和后端是完全独立的堆栈,应该不知道另一边发生了什么,我的论点是这就是一个rest API是为了……
  • 拥有一个与后端一起工作的前端是一回事,拥有一个与同一后端 API 的两种不同实现一起工作的前端是不同的联盟。总的来说这是一个好主意,但是为了测试而对同一个 API 进行第二次实现有点矫枉过正。

标签: javascript reactjs unit-testing mocking decoupling


【解决方案1】:

您正在寻找的是 Mock API。有很多包可以用来定义 JSON 格式的示例请求。其中许多还可以在短时间内处理持久数据。

从策略的角度来看,使用这些实际上可以使端到端测试自动化很有意义,这不应该依赖于生产 API。在单人团队中是否正确选择开发人员时间当然取决于长远的眼光;-)

【讨论】:

    猜你喜欢
    • 2014-11-01
    • 1970-01-01
    • 2023-03-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-05-13
    • 2019-02-20
    • 1970-01-01
    相关资源
    最近更新 更多