Deveroper メモ

記事内容に絶対の保証はなく..どちらかというと自分用のノウハウ蓄積ページ。 それでも良ければ見ていってください。

Gunma.web #52 テスト駆動開発

gunmaweb.connpass.com

表題の通り開催しました。 今回は あの @t_wada さんにお願いをして基調講演していただきました。

ちょうど前日に...

こんなブログの投稿があったもんだから、数人でワクワク感満載

t-wada.hatenablog.jp

t_wadaさん meet に来る

  • 会場の準備を済ませて、大型ディスプレイと繋げて PC を台上に置いて準備万端、あとは呼ぶだけ
  • 「初めまして」と数回お会いしたことはあるものの、こちらでは初めてだったので思わずこんな挨拶にw
  • 台上のPCを会場全体が見えるようにカメラを向けて欲しいと要望あり
    • 開催後、運営メンバーで「確かにオンラインで発表する側からしたら会場の雰囲気気になるよね」と
    • 幸い、ちょうどいい感じの高さの台で会場の雰囲気が伝わりやすいカメラ位置だった。
    • 次回オンラインでゲストを呼ぶ開催時の反省点としたい

いよいよ始まる

  • 当日の流れはこちら
  • やはりというか前日のブログ記事の話題に

FizzBuzz のTDD(ライブコーディング)

  • スムーズにライブコーディングというか、箇条書きにテストケースを同じ文脈に揃えることを解説しながらやってました。
    • 実際に自分でやるとなったら、ここまでスムーズは難しいよな。
    • 見せ方も非常に上手。確実に相手に伝わってる感ある

解説しながら用語など解説

  • テスト容易性
    • 観測容易性
    • 制御容易性
    • 小ささ
  • Humble Object Pattern
    • テスト容易性を低く下げている要素を薄く切り離すテクニック
    • 標準出力など
  • ToDoリスト作る段階が一番重要
    • テスト容易性 と 重要度 を 「高 」と「低 」に分割できれば勝ったようなもん
    • 同じ文脈で揃えていく
  • 3Aパターン
    • 準備:Arrange
    • 実行:Act
    • 検証:Assert
      • 検証から書く!
  • テストをゴール(Assert)から書くの最初むずいけど慣れると無駄な準備コードを書きすぎずにスムーズになるイメージ
  • 作りやすさに引っ張られると使いやすさが犠牲になる
    • 作る前に使う側に回ればその悲劇を回避できるのでは
  • 仮実装
    • テストを通過させるような簡単なコードをわざと書く
  • テストコードのテストは実装コードでやる
    • 実装コード(product code)をいじってわざと失敗させる
  • 三角測量
    • 2つ以上の値を使用しテストを書く
    • ここでテストが失敗するが、狙い通りの失敗 -> 失敗することを確認する
  • 明白な実装
    • 自信があれば = 明白な場合は 三角測量せずに本実装しても良い

ここに来て...バッドシナリオ!!

  • 動作する詳細設計書になっているか? -> 違った
    • 現場あるある話
  • 仕様の構造をテストコードの構造に落とし込む
    • テストコードを仕様書として読めるようにリファクタリング
    • テストの実行結果を粒度を揃えたツリー構造として表現する
  • 三角測量で書いたテストは不要なテストとなる可能性がある
    • 不要なもの = 意図が伝わらないものは未来のために消しておく
    • 残っていくテストのメンテナンスコストも考える

終盤

  • いよいよ完成系になってきたところで、TDDを続けていく上で必要なことを解説
  • テストがあると楽っていう体験をしてもらう

下記の記事の紹介

fortee.jp

gihyo.jp

質疑応答

  • DB にロジックを埋め込んでしまった場合はどのようにテストすればいいか?
    • DBから値を取得したという前提で、ロジックの部分を切り出してテストする
    • この本の紹介
    • 背景の後ろがリアル本棚で数人がビックリ!
  • 現場で実際には緊張したりする場で、重複がある事を気づかず次に行ってしまいがちになる事がある どうしたらいいか?(自分の質問でした)
    • コピペ判定ツールを使ってみる。
    • 構造化して、文脈で同じ事を気付きやすくする
  • etc...

t_wada さん発表時の slide

  • 今回のものが大体網羅されているので、これを貼り付けておきます。 speakerdeck.com

基調講演の後のLT

  • 素晴らしい発表のあとに LT をするのは緊張感半端ないですね。
  • 自分の LT はこれをしました。 speakerdeck.com

終わった後...

  • t_wada さんの発表は「TDD の良さはこれだよ!」と言いたくなるくらいに解りやすく伝わりやすいものでした。
    • 自分じゃこうは出来ないな〜汗
  • 特に感じたのは...
    • インクリメンタルな開発・設計 の部分ですね -> この言葉自体も今回がキッカケで知りました。
    • 頭の体操に近いとか感覚の話を後輩にするのですが、一番大切な要素は、動作する詳細仕様書(設計書)であり、「反復しながら動作を頭の中に整理しながら落とし込んでいく、人に優しい手法」だという事が伝わってない感あったのでいい経験になりました。
  • さて、来年度の研修資料を作り直すぞ〜!