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

by Yuichi Goto

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

テスト駆動開発との出会い • ≒ 和田さんとの出会い • 2013年、大学院生になって始めたエンジニアの  アルバイト先（ピクスタ）で出会う • 当時の認識: 「Wikipediaに載ってるすごい人に  技術コンサルティングをお願いしているらしい」 • しばらくは特に関わりがなかった 9 現在も引き続きお世話になっています

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

そして今日に至る • ペアプロを通じて和田さんに話しかけやすくなる • 曖昧な認識が議論・質問を通じて矯正されていく • DbC, DB設計, REST, キャリア設計など、テスト  駆動開発以外のことも和田さんから学ぶ • 今回書籍のレビュアーになり、少し恩返しできた感 12 和田さんに伺った話を再現することを「和田芸」と呼んでいます

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

目的を達成する手段はひとつではない • 実装の対象によって最良の手段は異なる • ロジックや振る舞い: これらのテストコードを使って実装を進める（または変更する）TDD • UIコンポーネントの見た目: 最初は目視確認で  実装を進め、回帰テストにSnapshotを使うSDD • 今後状況が変化すれば、また別の手段が出てくる 19

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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