继上一篇年轻时，我不写单元测试文章过后，我们开始在项目中引入了单元测试，希望能够通过单元测试提前发现问题，但是在实施中我们遇到了一个比较严重的问题：
复杂React组件的单元测试编写难度太大，导致大家不愿意编写单元测试
为了解决这个问题，我们做了积极的探索，首先，我们回归到我们引入单元测试的本质
希望单元测试解决什么问题？
- 面对复杂的业务场景，共用模块间难免会相互影响，希望用单元测试来覆盖原有逻辑，从而保证引入新逻辑，原有模块依然能够表现正常。
这时我们从目标结果反推方式，会发现我们偏移了我们的目标，我们并不希望界面上的ui也包含在我们的单元测试中，页面上ui交互的操作，应该是我们自测过程中，就能够自己发现的问题，而单元测试应该专注于逻辑的测试。基于这样的定位，我们回过头来，再来重新看我们的业务代码，就需要探索出一种新的React组件模式。
最终，我们借鉴了分层思想来去设计我们的React组件
我们将一个React组件，分成了UI交互层和逻辑处理层两部分
- UI交互层专注于交互以及UI的正常展示
- 逻辑处理层包括了一个一个的逻辑单元模块，去处理不同的业务逻辑，
利用纯函数的思想，去保证输入和输出的可控
通过这样的分层设计，我们将react中业务逻辑相关拆分出来，针对这样的一个一个单元模块，我们在编写相对应的测试用例，极大的降低了编写一个复杂组件的单元测试的成本。
继上一篇年轻时，我不写单元测试文章过后，我们开始在项目中引入了单元测试，希望能够通过单元测试提前发现问题，但是在实施中我们遇到了一个比较严重的问题：
为了解决这个问题，我们做了积极的探索，首先，我们回归到我们引入单元测试的本质
希望单元测试解决什么问题？
这时我们从目标结果反推方式，会发现我们偏移了我们的目标，我们并不希望界面上的ui也包含在我们的单元测试中，页面上ui交互的操作，应该是我们自测过程中，就能够自己发现的问题，而单元测试应该专注于逻辑的测试。基于这样的定位，我们回过头来，再来重新看我们的业务代码，就需要探索出一种新的React组件模式。
最终，我们借鉴了分层思想来去设计我们的React组件
我们将一个React组件，分成了UI交互层和逻辑处理层两部分
利用纯函数的思想，去保证输入和输出的可控
通过这样的分层设计，我们将react中业务逻辑相关拆分出来，针对这样的一个一个单元模块，我们在编写相对应的测试用例，极大的降低了编写一个复杂组件的单元测试的成本。