这是一次在公司内部的分享，当时觉得一个主题的时间太少，就准备了两个，所以可以看到这两个主题之间没有什么联系。
CSS Modules
css 之前一直存在着两个比较大的问题
- 无编程特性
- 类名全局污染
第一个问题已经有了很多成熟的方案，比如 sass, less。
第二个问题，最早的时候，也是通过约定命名规则来解决的，比如 BEM。这种解决方案有个问题就是造成了类名过长，比如
.TheStory__ofNamingConvention--whateverYouChoose.is-kindsOfLooong{}
当然最主要的问题还是很难保证团队的成员都会严格遵守这种命名规范，更好的做法应该是从工具层面去解决这个问题。
React 兴起之后，Facebook 提出一种激进的方案，CSS in JS。
当你已经习惯于写传统的 css，看到这种方案可能有点难以接受。还好还有 CSS Modules。
/* style.css */
.className {
color: green;
}
/* js file */
import styles from "./style.css";
element.innerHTML = '<div class="' + styles.className + '">';
CSS Modules 用 JS 来管理样式依赖，最终输出的时候，给每个类名加上一个 hash 值来避免冲突。具体用法可以看看这篇文章。
顺便插播一条软广，如果你在用 VSCode 的话，欢迎试下这个插件。
组件测试
前端测试，可以分为两点
- UI 测试（兼容性，样式）
- 逻辑性测试
这个主题主要是涉及第二点。
传统的前端测试都是针对一个函数方法，然而在 React 这种组件开发的方式兴起后，我们每天更多的是在写组件代码，所以这类测试变得越来越重要。
Facebook 自己也意识到这点，所以推出了一个针对组件测试的库，Jest，有两个比较重要的功能。
- DOM Testing
- Snapshot Testing
DOM Testing 像传统的断言测试一样，取渲染之后组件的某个属性，判断是不是期待的值。
const checkbox = shallow(
<CheckboxWithLabel labelOn="On" labelOff="Off" />
);
expect(checkbox.text()).toEqual('Off');
DOM Testing 的问题，或者说传统的测试代码的问题在于，你需要去写各种断言。想想你每天写的一大堆组件，还需要去给它们加上各种 expect。
Snapshot Testing 就会方便很多，先来看下代码，同样是上面的例子，可以写成
const checkbox = shallow(
<CheckboxWithLabel labelOn="On" labelOff="Off" />
);
expect(checkbox).toMatchSnapshot();
在代码量上面并没有什么减少，但是你不用自己手动去判断各种属性。每次只需要 toMatchSnapshot()。
Snapshot Testing 的做法是
- 第一次运行测试代码的时候，自动生成快照
- 当修改了组件代码之后，自动生成快照，并与上一次快照自行对比
- 如果对比的结果是你所预期的，只需要更新下快照。否则，你就知道修改的组件代码有问题。
DOM Testing 和 Snapshot Testing 的具体用法可以看看官方文档。
