异步队列

浏览器

微任务和宏任务

宏任务 微任务

Node



  1. setImmediate setTimeout
  2. program.nextTick()
  3. process.nextTick() setImmdeiate

测试

单元测试

单元测试能够让开发者明确知道代码结果

单一职责
接口抽像
层次分离
断言库： 保证最小单元是否正常运行检测方法
测试分割：
测试驱动开发TDD： 关注所有功能是否被实现

better-assert

行为驱动开发BDD 关注整体行为是否符合整体预期

should.js
expect.jsp
Jasmine.js

chai.js

Node.js require(“assert”)

单元测试运行流程
每一个测试用例组都通过describe进行设置
before
beforeEach
it expect(x).to.equal(true)
异步mocha ，mock
after
afterEach

自动化单元测试

karma 自动化runner集成 PhantomJS无刷新

npm install karma-cli -save-dev

npm install karma-chrome-lanucher –save-dev

npm install karma-phantomjs-launcher –save-dev

npm install karma-mocha –save-dev

npm insgall karma-chai

报告和单元测试覆盖率检查

npm 　 install karma-coverage –save-defineReactive

coverageReport(type: “html”, dir: ‘coverage/‘)

性能测试

基准测试

面向切面编程AOP无侵入式统计

Benchmark基准测试方法，他并不是简单的统计执行多少次测试代码对比时间，他对测试有着严格的抽样过程，执行多少次取决于采样到的数据能否完成统计，根据统计次数计算方差。

压力测试

PV网站当日访问人数
UV独立访问人数

QPS = PV/t；

ab 　-c 100 -n 100 http://localhost:8010

安全测试

XSS
SQL
CSRF

功能测试

selenium-webdirver
protractor selenium-standalone
http://webdirver.io/post
冒烟测试 SmokeTest
回归测试

jsLint JsHint

微前端弃用Iframe

但是大部分微前端方案又不约而同放弃了 iframe 方案，自然是有原因的，并不是为了 “炫技” 或者刻意追求 “特立独行”。
如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，

  1. 样式隔离、
  2. js 隔离这类问题统统都能被完美解决。

但他的最大问题也在于

  1. 他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。

其实这个问题之前这篇也提到过，这里再单独拿出来回顾一下好了。

  1. url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
  2. UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
  3. 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
  4. 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
    其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。

vite

vite配置 vite.config.js

1
2
3
4
module.exports = {
  // 添加请求前缀
  base: '/vite-vue/' 
}