Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テスト駆動開発と私 / TechBookWalk TDD
Search
Yuichi Goto
December 05, 2017
Programming
3
1.9k
テスト駆動開発と私 / TechBookWalk TDD
技術書の歩き方勉強会「テスト駆動開発」編(2017/12/05)
Yuichi Goto
December 05, 2017
Tweet
Share
More Decks by Yuichi Goto
See All by Yuichi Goto
あるRailsエンジニアがビジネスリーダーに転身するまで
yasaichi
8
2.2k
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
yasaichi
50
19k
Active Recordから考える次世代のRuby on Railsの方向性 / Directions for the next generation of Ruby on Rails: From the viewpoint of its Active Record
yasaichi
38
19k
ピクスタのエンジニアリングとCircleCI / Software Engineering with CircleCI at PIXTA
yasaichi
1
320
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?
yasaichi
139
85k
SSR以後の世界へ / techcamp05
yasaichi
3
1.5k
サービス開発の現場からOSSを生み出す思考技術 / genbaweb04
yasaichi
3
1.1k
Capybaraで変更に強いE2Eテストを書く / TokyuRubyKaigi12
yasaichi
6
2.1k
今更始めるGo言語 / techcamp04
yasaichi
0
2.9k
Other Decks in Programming
See All in Programming
Direct Style Effect Systems The Print[A] ExampleA Comprehension Aid
philipschwarz
PRO
0
230
GitHub Copilotのススメ
marcy731
1
240
新宿ダンジョンを可視化してみた
satoshi7190
3
420
“Seeing Like a Programmer”—Resiliency, Limits, and Moral Hazards in Software Engineering (LambdaConf 2024)
chriskrycho
0
290
if constexpr文はテンプレート世界のラムダ式である
faithandbrave
3
700
TCAとKMPを用いた新規動画配信アプリ 「ABEMA Live」の設計
tomu28
2
130
Docker_OSS_ホスティング入門
satokoki645
0
110
2 週間で Twitter Bot を作ってみた
contour_gara
0
800
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
utgwkk
6
1.9k
SIMD Parallel Programming with the Vector API
josepaumard
0
240
Ruby Function Composition
bkuhlmann
1
340
Git Lint
bkuhlmann
4
770
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
358
22k
Agile that works and the tools we love
rasmusluckow
325
20k
Designing for Performance
lara
601
67k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
Side Projects
sachag
451
41k
Building Effective Engineering Teams - LeadDev
addyosmani
32
1.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
Web Components: a chance to create the future
zenorocha
306
41k
The Pragmatic Product Professional
lauravandoore
26
5.8k
Visualization
eitanlees
137
14k
Six Lessons from altMBA
skipperchong
22
3k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
22
1.6k
Transcript
テスト駆動開発と私 Yuichi Goto (@_yasaichi) Dec 5, 2017 @ 技術書の歩き方勉強会「テスト駆動開発」編
self.inspect • ピクスタ株式会社 技術推進チームリーダー • Twitter: @_yasaichi • GitHub: yasaichi
• Blog: http://web-salad.hateblo.jp 2 他社さんにおける技術基盤の ようなチームです
https://pixta.jp クリエイターと購入者をつなぐデジタル素材のマーケットプレイス 3
Agenda テスト駆動開発(本)との関わり テスト駆動開発との出会い テスト駆動開発に対するスタンス まとめ 4
テスト駆動開発(本)との関わり • 原書(2002年)・旧訳版(2003年)ともに未読 • 原書の発売時は小学生 • 2013年のピアソンショックにより旧訳版は絶版に • 新訳版のレビュアー •
付録C 「訳者解説:テスト駆動開発の現在」を担当 5
付録Cについて • ざっくり言うと、和田さんによる良質なサーベイ論文 • 過去: テスト駆動開発の進化と普及の歴史 • 現在: 教条主義化と意味の希薄化 •
未来: これからのテスト駆動開発の学び方 • このためだけに本書を買ってもいいくらいの質の高さ 6
本文を読んで感じたこと • Kent Beckの思考過程を追える感覚、プライスレス • 思考過程は特定言語によらないので価値がある • ペアプロではなく書籍で伝えているのがすごい • 和田さんの訳注の質が高い
• 古くなった記述に「今はこうです」という補足がある 7
Agenda テスト駆動開発(本)との関わり テスト駆動開発との出会い テスト駆動開発に対するスタンス まとめ 8
テスト駆動開発との出会い • ≒ 和田さんとの出会い • 2013年、大学院生になって始めたエンジニアの アルバイト先(ピクスタ)で出会う • 当時の認識: 「Wikipediaに載ってるすごい人に
技術コンサルティングをお願いしているらしい」 • しばらくは特に関わりがなかった 9 現在も引き続きお世話に なっています
初めてのペアプログラミング • 2014年の春休みに大きめのリファクタ案件を任される • それまでは小さな改善タスクだけやっていたので、 テストを書く必要がなかった • 和田さんの「RSpecの入門とその一歩先へ」を写経し、 本文中の知らない単語を調べて下準備 •
人生初のペアプロを和田さんと行う(with RSpec) 10
テストにまつわる当初の認識 • 意味の希薄化(付録C参照)したTDD/BDDそのもの • テスト駆動開発 = テストを先に書くこと? • テストの書き方にはassertionとexpectationの 2つのスタイルがあり、RSpecは後者に属する
• double, stub, mockの違いがよくわからない 11
そして今日に至る • ペアプロを通じて和田さんに話しかけやすくなる • 曖昧な認識が議論・質問を通じて矯正されていく • DbC, DB設計, REST, キャリア設計など、テスト
駆動開発以外のことも和田さんから学ぶ • 今回書籍のレビュアーになり、少し恩返しできた感 12 和田さんに伺った話を再現する ことを「和田芸」と呼んでいます
Agenda ɹ テスト駆動開発(本)との関わり ɹ テスト駆動開発との出会い テスト駆動開発に対するスタンス まとめ 13
https://twitter.com/_yasaichi/status/936832539427094528 “テスト駆動開発は、「コードで記 述されたロジックや振る舞いを変更 する際に、フィードバックサイクル を⾼速で回すための現時点で最良の ⼿段」である” ― Yuichi Goto (
) 14
フィードバックサイクルという観点 • テストを書く・書いてあると個人的に嬉しいケース • テストを書く→仮実装→本実装の過程で • レガシーコード改善のお供として • Railsアップグレードの際の命綱として •
「変更の影響をすぐ知りたい」という点で目的が同じ 15
「ロジックや振る舞い」以外の場合は? • 例: コードで記述された「見た目」を変更する場合 • そもそも「どう見えるか?」をコードで記述できない • DOMやclass名などを使えば「見た目がどのように 構築されるか?」は記述できるが、壊れやすい •
より高速なフィードバックサイクルを達成するための 別の手段があるのでは? 16
https://medium.com/nulogy/storybook-driven-development-a3c517276c07 17 例えば、Storybook Driven Development (SDD)
SDDの実装・テストの流れ 1. 実装対象のUIコンポーネントの状態を全て列挙し、 Storyとして記述する 2. 各Storyで期待する見た目ができるまで、ブラウザ 上のレンダリング結果を目視確認しつつ実装する 3. 実装がひと通り終わったら、Snapshotを作成する 4.
以降はSnapshotを使って回帰テストを行う 18
目的を達成する手段はひとつではない • 実装の対象によって最良の手段は異なる • ロジックや振る舞い: これらのテストコードを使って 実装を進める(または変更する)TDD • UIコンポーネントの見た目: 最初は目視確認で
実装を進め、回帰テストにSnapshotを使うSDD • 今後状況が変化すれば、また別の手段が出てくる 19
Agenda ɹ テスト駆動開発(本)との関わり テスト駆動開発との出会い テスト駆動開発に対するスタンス まとめ 20
まとめ • 新訳版「テスト駆動開発」は原書の価値+和田さんの 訳・付録により現在においても手に取る価値のある本 • テスト駆動開発に対する私のスタンス • ロジックや振る舞いを変更する際に、フィードバック サイクルを高速で回すための現時点で最良の手段 •
銀の弾丸ではない(例: UIコンポーネントの見た目) 21
ご清聴ありがとうございました 22