React是一个View library，它干的活就是DOM domain里的两个事：渲染和捕获事情。我们在这里依然从简，只用stateless component这个子集，虽然在用到生命周期办法的时分需求用一下class，但绝大少数时分应该只用stateless component。
它以Virtual DOM的方式封装了恶心的阅读器基础设备，让我们以函数和数据结构来描画组件，所以和大部分框架不同，我们的测试依然可以在node上并行运转。假设用Karma + Chrome真正地渲染测试，你会发现共享一个阅读器实例的测试十分慢，简直无法watch测试，因此我们的TDD cycle就会变得不那么流利了。
最基本的就是 state => UI 这种纯函数组件：
const Greeter = ({ name }) => <p>Greetings {name}!</p>
运用的时分就像HTML一样传递attribute就可以了。
render(<Greeter name="React"/>, document.body)
最复杂的测试还是判等，我们用一个叫 jsx-test-helpers 的库来帮我们渲染：
import { renderJSX, JSX } from 'jsx-test-helpers'
const Paragraph = ({ children }) => <p>{children}</p>
const Greeter = ({ name }) => <Paragraph>Greetings {name}!</Paragraph>
test('Greeter', t => {
t.is(renderJSX(<Greeter name="React"/>),
JSX(<Paragraph>Greetings React!</Paragraph>),
'should render greeting text with name')
})
这里我多加了一层叫做Paragraph的组件，它的作用仅仅是传递给p标签，children这个prop表示XML标签传出去的子元素。多加这层Paragraph是为了展现renderJSX只向下渲染了一层，而非最终需求渲染的p标签。这样我们在View上的测试粒度就会变得更小，成本更低，速度更快。
View不像业务本身那么波动，细粒度低成本的快速测试更划算些，这也是为什么我们的View都只是接受参数渲染，这样你只用测很少的case就能保证View可以正确渲染。假设你的FSM Model有M种能够性，View显示的逻辑有N种，假设将两个集成在一同测试能够就需求M×N种Path，假设分开测就有M+N种。View和Model的边界明晰时，你的Model测试不容易被更困难的View测试搅扰，View测试也增加了混沌水平，需求测试的情形就增加了。
我们的组件不应该只要渲染，还有事情，比如我们封装个TextField组件：
const TextField = ({ label, onChange }) => <label>
{label}
<input type="text" onChange={onChange} />
</label>
当然我们还可以判等，只需onChange函数援用相反就好了。
test('TextField', t => {
const onChange = () => {}
const actual = renderJSX(<TextField label="Email" onChange={onChange} />)
const expected = JSX(<label>
<input type="text" onChange={onChange}/>
</label>)
t.is(actual, expected)
})
当然有时分你的组件更复杂些，测试时并不关心组件是不是完全按你想要的样子渲染，能够你想像 jQuery 一样选择什么，触发什么。这样可以用更主流的 enzyme 来测试：
import {shallow} from 'enzyme'
import sinon from 'sinon'
test('TextField with enzyme', t => {
const onChange = sinon.spy()
const wrapper = shallow(<TextField label="Email" onChange={onChange} />)
(责任编辑：admin)