テスト駆動開発と私 / TechBookWalk TDD

技術書の歩き方勉強会「テスト駆動開発」編（2017/12/05）

Transcript

1. テスト駆動開発と私
   Yuichi Goto (@_yasaichi)
   Dec 5, 2017 @ 技術書の歩き方勉強会「テスト駆動開発」編
   

   View Slide

2. self.inspect
   • ピクスタ株式会社　
   技術推進チームリーダー
   • Twitter: @_yasaichi
   • GitHub: yasaichi
   • Blog: http://web-salad.hateblo.jp
   2
   他社さんにおける技術基盤の
   ようなチームです
   

   View Slide

3. https://pixta.jp
   クリエイターと購入者をつなぐデジタル素材のマーケットプレイス
   3
   

   View Slide

4. Agenda
   テスト駆動開発（本）との関わり
   　 テスト駆動開発との出会い
   　 テスト駆動開発に対するスタンス
   　 まとめ
   4
   

   View Slide

5. テスト駆動開発（本）との関わり
   • 原書（2002年）・旧訳版（2003年）ともに未読
   • 原書の発売時は小学生
   • 2013年のピアソンショックにより旧訳版は絶版に
   • 新訳版のレビュアー
   • 付録C 「訳者解説：テスト駆動開発の現在」を担当
   5
   

   View Slide

6. 付録Cについて
   • ざっくり言うと、和田さんによる良質なサーベイ論文
   • 過去: テスト駆動開発の進化と普及の歴史
   • 現在: 教条主義化と意味の希薄化
   • 未来: これからのテスト駆動開発の学び方
   • このためだけに本書を買ってもいいくらいの質の高さ
   6
   

   View Slide

7. 本文を読んで感じたこと
   • Kent Beckの思考過程を追える感覚、プライスレス
   • 思考過程は特定言語によらないので価値がある
   • ペアプロではなく書籍で伝えているのがすごい
   • 和田さんの訳注の質が高い
   • 古くなった記述に「今はこうです」という補足がある
   7
   

   View Slide

8. Agenda
   　 テスト駆動開発（本）との関わり
   テスト駆動開発との出会い
   　 テスト駆動開発に対するスタンス
   　 まとめ
   8
   

   View Slide

9. テスト駆動開発との出会い
   • ≒ 和田さんとの出会い
   • 2013年、大学院生になって始めたエンジニアの

   アルバイト先（ピクスタ）で出会う
   • 当時の認識: 「Wikipediaに載ってるすごい人に

   技術コンサルティングをお願いしているらしい」
   • しばらくは特に関わりがなかった
   9
   現在も引き続きお世話に
   なっています
   

   View Slide

10. 初めてのペアプログラミング
    • 2014年の春休みに大きめのリファクタ案件を任される
    • それまでは小さな改善タスクだけやっていたので、
    テストを書く必要がなかった
    • 和田さんの「RSpecの入門とその一歩先へ」を写経し、
    本文中の知らない単語を調べて下準備
    • 人生初のペアプロを和田さんと行う（with RSpec）
    10
    

    View Slide

11. テストにまつわる当初の認識
    • 意味の希薄化（付録C参照）したTDD/BDDそのもの
    • テスト駆動開発 ＝ テストを先に書くこと？
    • テストの書き方にはassertionとexpectationの

    2つのスタイルがあり、RSpecは後者に属する
    • double, stub, mockの違いがよくわからない
    11
    

    View Slide

12. そして今日に至る
    • ペアプロを通じて和田さんに話しかけやすくなる
    • 曖昧な認識が議論・質問を通じて矯正されていく
    • DbC, DB設計, REST, キャリア設計など、テスト

    駆動開発以外のことも和田さんから学ぶ
    • 今回書籍のレビュアーになり、少し恩返しできた感
    12
    和田さんに伺った話を再現する
    ことを「和田芸」と呼んでいます
    

    View Slide

13. Agenda
    ɹ テスト駆動開発（本）との関わり
    ɹ テスト駆動開発との出会い
    テスト駆動開発に対するスタンス
    　 まとめ
    13
    

    View Slide

14. https://twitter.com/_yasaichi/status/936832539427094528
    “テスト駆動開発は、「コードで記
    述されたロジックや振る舞いを変更
    する際に、フィードバックサイクル
    を⾼速で回すための現時点で最良の
    ⼿段」である”
    ― Yuichi Goto ( )
    14
    

    View Slide

15. フィードバックサイクルという観点
    • テストを書く・書いてあると個人的に嬉しいケース
    • テストを書く→仮実装→本実装の過程で
    • レガシーコード改善のお供として
    • Railsアップグレードの際の命綱として
    • 「変更の影響をすぐ知りたい」という点で目的が同じ
    15
    

    View Slide

16. 「ロジックや振る舞い」以外の場合は？
    • 例: コードで記述された「見た目」を変更する場合
    • そもそも「どう見えるか？」をコードで記述できない
    • DOMやclass名などを使えば「見た目がどのように
    構築されるか？」は記述できるが、壊れやすい
    • より高速なフィードバックサイクルを達成するための
    別の手段があるのでは？
    16
    

    View Slide

17. https://medium.com/nulogy/storybook-driven-development-a3c517276c07 17
    例えば、Storybook Driven Development (SDD)
    

    View Slide

18. SDDの実装・テストの流れ
    1. 実装対象のUIコンポーネントの状態を全て列挙し、

    Storyとして記述する
    2. 各Storyで期待する見た目ができるまで、ブラウザ

    上のレンダリング結果を目視確認しつつ実装する
    3. 実装がひと通り終わったら、Snapshotを作成する
    4. 以降はSnapshotを使って回帰テストを行う
    18
    

    View Slide

19. 目的を達成する手段はひとつではない
    • 実装の対象によって最良の手段は異なる
    • ロジックや振る舞い: これらのテストコードを使って
    実装を進める（または変更する）TDD
    • UIコンポーネントの見た目: 最初は目視確認で

    実装を進め、回帰テストにSnapshotを使うSDD
    • 今後状況が変化すれば、また別の手段が出てくる
    19
    

    View Slide

20. Agenda
    ɹ テスト駆動開発（本）との関わり
    　 テスト駆動開発との出会い
    　 テスト駆動開発に対するスタンス
    まとめ
    20
    

    View Slide

21. まとめ
    • 新訳版「テスト駆動開発」は原書の価値＋和田さんの
    訳・付録により現在においても手に取る価値のある本
    • テスト駆動開発に対する私のスタンス
    • ロジックや振る舞いを変更する際に、フィードバック
    サイクルを高速で回すための現時点で最良の手段
    • 銀の弾丸ではない（例: UIコンポーネントの見た目）
    21
    

    View Slide

22. ご清聴ありがとうございました
    22
    

    View Slide