🤖 Deploying to gh-pages from master 85e7a6a

_posts/2023-12-10-react-unit-testing-best-practices.md

@@ -25,17 +25,17 @@ tags: react unit-test tdd rtl react-testing-library jest design-system
 
 ## 目录
 
-* 与上一版的变化
-* 什么是无效的自动化测试？
-* React架构与测试策略
-* 测试架构、代码落地
-* 新的衍生问题
-* 总结：优势 & 挑战
+* 与上一版的变化 (Difference with earlier recommended practice)
+* 有效的自动化测试 v.s 无效的自动化测试 (Automated Tests Best Practice v.s Anti Practice)
+* React架构与测试策略 (React Architecture & Testing Strategies)
+* 测试架构、代码落地 (Test Architecture & Implementation)
+* 新的衍生问题 (Arising Problems)
+* 总结：优势 & 挑战 (Summary: Advantages & Challenges)
 * Q & A
 
 > 🚧正文内容正在施工中。
 
-## 与上一版的变化
+## 与上一版的变化 Difference with earlier recommended practice
 
 如果你之前未读过我的前作[《React单元测试策略及落地》][react单元测试策略]，那么本节你自可跳过。
 
@@ -52,22 +52,26 @@ tags: react unit-test tdd rtl react-testing-library jest design-system
  * 组件层，原来的策略是只测逻辑，新策略中建议是拉通hooks一起测，并且要测试页面内容。这是本篇最大的变化（和精华）。
 * “(单元)测试落地”这部分，本篇给出了大量基于新的单元测试策略的代码。
 
-## 什么是无效的自动化测试？/ 什么是有效的自动化测试？
+## 有效的自动化测试 v.s 无效的自动化测试 Automated Tests Best Practice v.s Anti Practice
 
-那么，什么是有效的自动化测试呢？
+前面讲了<WIP>。那么，什么是有效的自动化测试呢？
 
 * 支撑重构
-* ne
+* 有效留存业务上下文：表达力强
+
+表达力强好理解：
+
+* 
 
 > 🚧从上一篇抄一些过来。
 
-支撑重构的测试一直是我强调的一个最最重要的点。不能支撑重构的测试还留着过年吗？那么什么叫支撑重构的测试呢？
+**支撑重构的测试**，其重要性怎么强调都不为过，它是实施自动化测试关键中的关键。不能支撑重构的测试~~还留着过年吗~~，只会让测试变成为了交差而不得不完成的任务，改了代码还得修改测试，甚至我重构实现不改动功能还得修改大范围挂掉的测试。这样的测试妥妥地是实现功能的阻力而不是助力，是无效的自动化测试。那么什么才是有效的、能够支撑重构的测试呢？归纳来说，它必须符合
 
 * 与当前测试相关的功能点变化了/改坏了，当前测试必须失败
 * 与当前测试相关的功能点没变化/没改坏，但是内在的实现细节改变了，当前测试必须仍然通过
 * 与当前测试无关的功能点变化了/改坏了，当前测试必须仍然通过，必须有其他测试失败
 
-这么说是挺抽象的。我们直接来上手看几个例子。
+这么说对于没有实践经验的同学来说是挺抽象的。所以我们直接上手来看几个例子。
 
 * 断言细节与测试意图相差太远：不好调试、不好理解、挂了不知道咋回事、留不住业务上下文，除了刷覆盖率，对实际的代码质量、稳定性、后续维护基本是拖后腿的状态。
  * 不做精准断言，满篇都是`expect('一些字符').toBeInTheDocument()`。<有啥问题？①字如果是同样的/过于普遍（比如断言$20应该在页面上，鬼知道这啥意思？再者假设你是这么个应用，月付$20，年付只要$208(-32/↓15%)，你断言月付但其实年付也有$20，你改坏了月付，年付还在呢，测试不会挂，但是你的功能坏了。这就是所谓不支持重构的测试），哪哪都有，起不到测试效果；②看了就生气，测的这是啥；③不支持重构>