【问题标题】:A way of testing javascript/typescript in browser after bundling捆绑后在浏览器中测试 javascript/typescript 的一种方法
【发布时间】:2022-11-10 14:27:40
【问题描述】:

我正在和我的朋友一起写一个网络应用程序。他写前端,我写后端。问题是,如果我的朋友还没有编写集成,我无法测试我的代码,因为我们将代码捆绑在 webpack 中并在开发服务器上运行它。我的问题是,有没有一种方法可以在 chrome 控制台中测试我的打字稿代码(带参数的调用函数),就像我可以测试未捆绑的 javascript 一样?

【问题讨论】:

  • 通常,您应该能够分别运行服务器和客户端构建。为了测试服务器端代码(后端)的 API,您将编写一组单元测试,使用类似 node-fetch 的方式调用 API,并使用客户端发送的数据并检查 API 是否返回预期结果。除此之外,您将编写一个单元测试,直接对后端代码的不同功能分别进行处理。 (您不会从 chrome 控制台测试后端代码)
  • @t.niese 问题是后端位于客户端。也许我说错了,但我所说的后端是应用程序的内部机制。我想测试连接到服务器而不是服务器

标签: javascript typescript bundle bundler snowpack


【解决方案1】:

专业的答案是:不要那样做!

  • 使用Postman 测试实际服务器。
  • 通过 jest 或其他一些单元测试库为您的 api 处理客户端代码编写单元测试,以拦截对服务器的调用(因为这些不是单元测试)。
  • 为实际上不涉及中间代码的前端编写单元测试。
  • 尽可能将单元测试转换为断言,因为案例覆盖率胜过代码覆盖率,而且您不可能在单元测试期间考虑所有事情。
  • 编写以用户为中心而非以小部件为中心的集成测试。

这很难,但你会很高兴你做到了......如果你能做到这一点,而项目不会因此而死亡!对于一个只有你和一个朋友的项目,这可能是一个巨大的“如果”!

所以实际的答案可能是:写...或让您的朋友写...一个丑陋但功能强大的页面,您可以使用该页面输入一些值并单击按钮提交,然后在附近添加debugger作为声明按钮代码的开始。 debugger 是开发工具将暂停的硬代码断点。

一旦编写并工作,您应该能够根据需要对其进行修改。 ...请记住不要让该页面逃逸到生产中。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-07-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-07-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多