Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TDD実践を経て変わったこと

tkitsunai
April 27, 2021

 TDD実践を経て変わったこと

Qiita × Uzabase Tech Meetup#1
技術講演②「TDD実践を経て変わったこと」
で発表した内容になります。

https://connpass.com/event/210103/

tkitsunai

April 27, 2021
Tweet

More Decks by tkitsunai

Other Decks in Programming

Transcript

  1. テスタビリティが何故指標として役立つのか 1. テスタビリティが低い場合、様々な課題があることに気付いた a. 独立性が低い b. 密結合になりやすい c. 責務がバラけがち 2.

    設計を議論する時に、テスタビリティの観点で話すことが出来る 3. テストがやり難いと感じたとき、設計を見直すことのできるチャンスだと捉えることができる
  2. 実装の仕方の変化 テストは、実装が正しいことを検証するためのみ に存在していた。 後でテスト書くため、テストが実装に依存する。 結果として次のようなことが起きていた。 1. テスト自体が複雑になっていた 「検証のためだから許容しよう」と考えてしまっていた。 2. 余計な検証をしていた

    例: 一つのテストケースにアサートが複数あり、一緒くたに様々な検証をしている。 3. 必要以上に実装してしまっていた なんとなく実装するとやってしまいがち。 (YAGNIはどこいったの?) なんとなく野菜を買ったけど、 こんなにいらなかった・・・
  3. 実装の仕方の変化 課題の解決法の例 1. アサートファースト アサートから書くと以下のようにシンプルに分けて考えられるようになる。 1.1. 期待値を明確にすることを考える(というかせざるを得ない)。 1.2. どう検証すべきかを考える。 2.

    テストの独立性を保つ 例えばアサートを一つにする。すると自然と検証内容もシンプルになる。 3. 最初はシンプルな1パターンのみ考える。(複数パターンの検証が考えられる場合) こうすると、実装の際はシンプルな一つの仕様を満たすことだけを考えればよく、実装も最 初は最小限度となる。更に自然とテストもアサートが 1つになっていく。