這個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的節奏：紅（失敗測試）、綠（產品代碼）、藍（重構） 理解測試驅動設計的一種運用場景。 ...
