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

Transcript

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

2. self.inspect • ピクスタ株式会社　 技術推進チームリーダー • Twitter: @_yasaichi • GitHub: yasaichi

   • Blog: http://web-salad.hateblo.jp 2 他社さんにおける技術基盤の ようなチームです

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

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

5. テスト駆動開発（本）との関わり • 原書（2002年）・旧訳版（2003年）ともに未読 • 原書の発売時は小学生 • 2013年のピアソンショックにより旧訳版は絶版に • 新訳版のレビュアー •

   付録C 「訳者解説：テスト駆動開発の現在」を担当 5

6. 付録Cについて • ざっくり言うと、和田さんによる良質なサーベイ論文 • 過去: テスト駆動開発の進化と普及の歴史 • 現在: 教条主義化と意味の希薄化 •

   未来: これからのテスト駆動開発の学び方 • このためだけに本書を買ってもいいくらいの質の高さ 6

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

   • 古くなった記述に「今はこうです」という補足がある 7

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

9. テスト駆動開発との出会い • ≒ 和田さんとの出会い • 2013年、大学院生になって始めたエンジニアの
 アルバイト先（ピクスタ）で出会う • 当時の認識: 「Wikipediaに載ってるすごい人に


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

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

    人生初のペアプロを和田さんと行う（with RSpec） 10

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

    • double, stub, mockの違いがよくわからない 11

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


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

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

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

    ) 14

15. フィードバックサイクルという観点 • テストを書く・書いてあると個人的に嬉しいケース • テストを書く→仮実装→本実装の過程で • レガシーコード改善のお供として • Railsアップグレードの際の命綱として •

    「変更の影響をすぐ知りたい」という点で目的が同じ 15

16. 「ロジックや振る舞い」以外の場合は？ • 例: コードで記述された「見た目」を変更する場合 • そもそも「どう見えるか？」をコードで記述できない • DOMやclass名などを使えば「見た目がどのように 構築されるか？」は記述できるが、壊れやすい •

    より高速なフィードバックサイクルを達成するための 別の手段があるのでは？ 16

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

18. SDDの実装・テストの流れ 1. 実装対象のUIコンポーネントの状態を全て列挙し、
 Storyとして記述する 2. 各Storyで期待する見た目ができるまで、ブラウザ
 上のレンダリング結果を目視確認しつつ実装する 3. 実装がひと通り終わったら、Snapshotを作成する 4.

    以降はSnapshotを使って回帰テストを行う 18

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


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

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

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

    銀の弾丸ではない（例: UIコンポーネントの見た目） 21

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