![[社内勉強会レポート] 『テスト駆動開発』読書勉強会 #3](https://devio2023-media.developers.io/wp-content/uploads/2017/11/tdd-reading-study.jpg)
[社内勉強会レポート] 『テスト駆動開発』読書勉強会 #3
はじめに
おばんです、先日仙台に帰った際に松島にある円通院のライトアップを見てきた田中です。ライトアップで照らされた紅葉が院内の小池に鏡のように映し出されるのがとても美しかったです。
さて本題に入っていきましょう。
この会の趣旨
この会の趣旨については、第一回のまとめをご覧ください。
それではまとめていきます。
6章 「テスト不足に気づいたら」
概要
5章でコピーアンドペーストしたコードを綺麗にするために、２つのクラスの親クラスとしてMoneyクラスを導入し、#equalsの実装を共通化した章。
話し合われた内容
- Francクラスのequalsに対するテストがない事に気づいてテストを追加した
- ここではequalsに対するテストがないことに気づけたが、テストが十分かどうかはどうやって判断するのか？
7章 「疑念をテストに翻訳する」
概要
DollarとFrancという異なる国籍の通貨を比較したらどうなるだろう？という疑念をテストによって検証する章。
話し合われた内容
- getClass()を使って２つのインスタンスのクラスが等しい場合のみ等価であると判定することにした
- JSではクラスの判定をどのように実装したらいいだろうか？
8章 「実装を隠す」
概要
DollarとFrancの重複を消すための準備をした章。
話し合われた内容
- 重複を除去できる状態に近づけるためにDollarとFrancにある２つのメソッドのtimesメソッドのシグニチャを合わせた
- メソッド宣言を親クラスに移した
- FactoryMethodパターンを導入してテストコードから２つのクラスの存在を隠した
- FactoryMethodいいよね（サブクラスのバリエーションを気にしなくて良いわかりやすいAPIになるので）
9章 「歩幅の調整」
概要
通過の概念(Currency)を導入して、サブクラスの実装をさらに近づけて行った章。
話し合われた内容
- 実際にコードを書いていると、本筋から派生してきになることが次々出てくるので「気になって調べた割り込みに割り込みはしない」はいいルールだと思う
- 歩幅の調整について、小さいステップを踏まないといけないわけではなくて、必要ならそうすることができる。確信持てる範囲でやっていくのが重要。
- 歩幅の決め方はどうするの？→確信を持てる範囲、迷いがある場合は狭める、迷いがある場合はいつでもフォールバックできる。
- １〜4章で行なっていたゼロから作る仮実装→修正も、７〜9章でやってきたような大きなリファクタリングも小さな歩幅で進めていけばいいことがわかった。
Javaで実装されているサンプルコードをJS、Swiftで実装するにあたって次のような議論がそれぞれ行われた
- 「getClass()を使って２つのインスタンスのクラスが等しい場合のみ等価であると判定することにした」をJSでどのように実装するか?
- →
this.constructor === other.constructor && this.amount === other.amountとコンストラクタを比較することにした
- →
- Moneyが抽象クラス化されてtimesメソッドが抽象メソッドになってるあたり、swiftではどうやって表現しようか??
まとめ
TDDの手法を、ステップを踏んで学ぶところからさらに一歩進んで、TDDから設計について考慮することに踏み出していくようになりました。
写経については「Javaだからこその書き方」から、Swiftではどう書くべきか、JavaScriptではどう書くべきかといったところに悩むようになってきました。最近聞いた以下のラジオでは、言語によって歩幅が変わったり、そもそも実装が省略されるということは「言語の進化である」と語られていました。様々な言語で書いていくとこういった差分を楽しめて良いですね。
実際に本を読んでいる方がこのエントリを読んで、参考になることがあれば幸いです。
