読者です 読者をやめる 読者になる 読者になる

つれズレ日記

Web&Androidのひよっこエンジニア♀のひとりごと。おいしいものとカメラと邦画とスポーツ観戦が大好き。

【勉強会】TDD実践講座に参加しました

アジャイルアカデミーのTDD実践講座に参加しました。
よく考えたら、ハンズオン形式の講座に参加したの初めてだったかも。

講義の内容を自分で咀嚼したものをメモ書きしておきますφ(*'д'* )メモメモ
くどいですがあくまでも【memo】ですwあしからず。

 

TDD(テスト駆動開発)とは
『動作するキレイなコード』を目指す手法、ツール
⇒TDD自体が目的ではない

TDDをやりたい、やってみたい
⇒背景、解決したい課題、その先に目的がある

  • コードが複雑で何してるのか(何がしたいのか)わからない
    ⇒触れるな危険
  • コードを変えてみたら予期せぬ影響が出た
  • バグを直したつもりなのにまたバグが生まれた
  • リリース間際に修正したけどテストする時間がない
  • たぶん動くからリリースしようぜ(略

動作するコードとは
動くもの ※ココではバグの有無を問わない

キレイなコードとは
バグ対応、追加変更が簡単にできる
実装者の意図がわかる
作業が予測できる(≒変えてみたら予期せぬ影響が…!なんてことが起きにくい)

 動作するキレイなコードへの道のり

  • 動くようにキレイに書く
    ⇒相当なスキルが必要。2つ考えるから頭も忙しい。もしかしたらセンスも必要かもw
  • キレイなコードを書いて動くようにしていく
    ⇒キレイな設計には際限がない、想定外のことが起きやすい
  • 動くコードを書いてキレイにしていく ←コレがTDD
    ⇒まずはどんな形でも動くようにする
     動作を保ったまま、中身をキレイにしていく ←テストが動作を保証する

TDDのサイクル

  1. 目標を考える
  2. その目標を示すテストを書く
  3. 実行して失敗させる(Red)
  4. 目的のコードを書く
  5. テストを成功させる
  6. 成功を維持したままリファクタリングを繰り返す
  7. 次の目標を考える
  8. 1~7を繰り返す…

まずゴールから書き始める
テストコードのテストは目的のコードが行う
実装前にわざと間違いを入れて実行するとテストが失敗する
(何もせず定数returnとかで試す)

TDDのこころ

  • ひとつずつ少しずつ段を小さく
  • 複数の問題を同時に相手にしない、ひとつずつ対処する
  • 素早くまわす
  • 自分が最初のユーザーになる
    ⇒そのメソッドをどうやって使うのかをテストに書ける
  • 不安をテストにする
    ⇒祈ってもダメ
  • 命綱を編む
    ⇒コードを変更した時にバグを生んでも気付ける
  • これってどうなるんだ?も考えすぎずにとりあえず動かしてみる

テストコードは動くドキュメント

  • 他者が意図を読めるように書く
  • テストメソッド名に躊躇なく日本語を使うのもOK
  • 全てのテストで必要な処理は共通メソッド化する
  • 渡すデータが違うだけのテストは共通化できる…←テストのリファクタリング

TDDはスキルであり、センスや才能ではない
練習すればできるようになる