这个TDD的步子很好，任务分解的粒度也很合适，不过考不考虑用面向对象的思路实现一个呢？
第一个测试表达的意图其实不很清晰，用数字描述每击得分、用20来描述总击球次数（然后疑问不是21次么？）、roll(3, 18)是什么意思？感觉丢失了“Frame”这个重要的概念，使得代码一切都是数字操作，不好辨别主要的业务逻辑。可能这就是纯函数式的缺点吧。
对我来说，从上一篇的需求图里我会设计出来的API可能是：
```
describe('BowlingGame', () => {
it('', () => {
const game = new BowlingGame()
game.fromRecord('35 27 4/ 5/ X 13 2/ 8/ X 5/9')
expect(game.getTotalScore()).toBe(147)
})
})
```
TDD Kata - 保龄球（Bowling）Coding阅读本文后，希望你能够有如下收获： 能够采用TDD的方式实现保龄球业务需求。 掌握TDD的节奏：红（失败测试）、绿（产品代码）、蓝（重构） 理解测试驱动设计的一种运用场景。 ...
