Submit Search
Upload
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
•
79 likes
•
16,703 views
Kei Sawada
Follow
#TDDBC in Tokyo 1.5でのLT資料
Read less
Read more
Technology
Business
Report
Share
Report
Share
1 of 38
Download now
Download to read offline
Recommended
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
Yoichi Tamamaki
Ruby でつくる型付き Ruby
Ruby でつくる型付き Ruby
mametter
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
Itsuki Kuroda
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版
Hiroki Kondo
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
Takuto Wada
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Recommended
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
Yoichi Tamamaki
Ruby でつくる型付き Ruby
Ruby でつくる型付き Ruby
mametter
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
Itsuki Kuroda
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版
Hiroki Kondo
TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
Takuto Wada
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
マイクロサービスにおけるテスト自動化 with Karate
マイクロサービスにおけるテスト自動化 with Karate
Takanori Suzuki
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
大貴 蜂須賀
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
Takuya Sato
"Simple Made Easy" Made Easy
"Simple Made Easy" Made Easy
Kent Ohashi
XSS再入門
XSS再入門
Hiroshi Tokumaru
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Yusuke Suzuki
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Yusuke Suzuki
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
Takuto Wada
探索的テスト入門
探索的テスト入門
H Iseri
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
Hironobu Isoda
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
mosa siru
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011
H Iseri
アジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これから
Kei Sawada
More Related Content
What's hot
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
マイクロサービスにおけるテスト自動化 with Karate
マイクロサービスにおけるテスト自動化 with Karate
Takanori Suzuki
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
大貴 蜂須賀
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
Takuya Sato
"Simple Made Easy" Made Easy
"Simple Made Easy" Made Easy
Kent Ohashi
XSS再入門
XSS再入門
Hiroshi Tokumaru
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Yusuke Suzuki
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Yusuke Suzuki
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
Takuto Wada
探索的テスト入門
探索的テスト入門
H Iseri
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
Hironobu Isoda
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
mosa siru
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
What's hot
(20)
テストコードの DRY と DAMP
テストコードの DRY と DAMP
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
マイクロサービスにおけるテスト自動化 with Karate
マイクロサービスにおけるテスト自動化 with Karate
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
"Simple Made Easy" Made Easy
"Simple Made Easy" Made Easy
XSS再入門
XSS再入門
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
DockerとPodmanの比較
DockerとPodmanの比較
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
探索的テスト入門
探索的テスト入門
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
リーン開発の本質 公開用
リーン開発の本質 公開用
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
Viewers also liked
ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011
H Iseri
アジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これから
Kei Sawada
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
Yohei Sato
テスト駆動開発入門
テスト駆動開発入門
Shuji Watanabe
TDDBC Fukuoka Day1
TDDBC Fukuoka Day1
Takuto Wada
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
Amazon Web Services Japan
Viewers also liked
(6)
ユニットテストの保守性を作りこむ, xpjugkansai2011
ユニットテストの保守性を作りこむ, xpjugkansai2011
アジャイル開発とTDDを半年間実践してみた顛末と、これから
アジャイル開発とTDDを半年間実践してみた顛末と、これから
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
テスト駆動開発入門
テスト駆動開発入門
TDDBC Fukuoka Day1
TDDBC Fukuoka Day1
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
AWS Black Belt Tech シリーズ 2015 - AWS Data Pipeline
Similar to TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
Sue445 Style TDD #atest_hack
Sue445 Style TDD #atest_hack
Go Sueyoshi (a.k.a sue445)
Grand Strategy For Presentation
Grand Strategy For Presentation
bash0C7
リーダブルコードを読んだ後
リーダブルコードを読んだ後
Kouhei Sutou
Tddのすゝめ
Tddのすゝめ
将 高野
TDDを研ぎ究める
TDDを研ぎ究める
pocketberserker
リーダブルコード 1.0'
リーダブルコード 1.0'
Yamamura Takashi
DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す
Kiro Harada
TDD を自分の道具にしよう
TDD を自分の道具にしよう
Yuji Okazawa
Node js 入門
Node js 入門
Satoshi Takami
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Takafumi ONAKA
nseg第5回勉強会
nseg第5回勉強会
ko ty
TDDはじめる前に
TDDはじめる前に
Yasui Tsutomu
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
ques_staff
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
Tomomi Kajita
仕様七変化
仕様七変化
galluda
とある Perl Monger の働き方
とある Perl Monger の働き方
Yusuke Wada
資料
資料
Bob_Mk2
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
Masahiro Wakame
java-ja TDD 2nd
java-ja TDD 2nd
Takuto Wada
Start!! Ruby
Start!! Ruby
mitim
Similar to TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
(20)
Sue445 Style TDD #atest_hack
Sue445 Style TDD #atest_hack
Grand Strategy For Presentation
Grand Strategy For Presentation
リーダブルコードを読んだ後
リーダブルコードを読んだ後
Tddのすゝめ
Tddのすゝめ
TDDを研ぎ究める
TDDを研ぎ究める
リーダブルコード 1.0'
リーダブルコード 1.0'
DDDをScrumで廻す あるいは ScrumをDDDで廻す
DDDをScrumで廻す あるいは ScrumをDDDで廻す
TDD を自分の道具にしよう
TDD を自分の道具にしよう
Node js 入門
Node js 入門
マジカルsvnとキュアgit
マジカルsvnとキュアgit
nseg第5回勉強会
nseg第5回勉強会
TDDはじめる前に
TDDはじめる前に
KDDI Business ID におけるアジャイル開発と検証フロー
KDDI Business ID におけるアジャイル開発と検証フロー
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
TDDを一年やってみました ~シロート集団がTDDをやってはまったこと~
仕様七変化
仕様七変化
とある Perl Monger の働き方
とある Perl Monger の働き方
資料
資料
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
TypeScript 型定義ファイルのある開発 TypeScript勉強会 VSハッカソン倶楽部
java-ja TDD 2nd
java-ja TDD 2nd
Start!! Ruby
Start!! Ruby
Recently uploaded
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Hiroshi Tomioka
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
WSO2
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
sn679259
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
Recently uploaded
(12)
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
1.
TDDを実践してわかった TDDつまづくあるあると 自分なりの乗り越え方まとめ
@remore
2.
今日、 僕たちが 経験すること
3.
4.
Kent Beck wrote: TDDは分析技法および設 計技法であり、実際には 開発のすべてのアクティ ビティを構造化するため
の技法である。 テスト駆動開発入門 p199
5.
「TDDは分析技法 および設計技法」
6.
7.
「TDD=テスト ファースト?」 「テストコードを書く
だけでしょ?」
8.
____
/⌒ ⌒\ /( ●) (●)\ /::::::⌒(__人__)⌒::::: \ 簡単だお! | |r┬-| | \ `ー'´ / 3か月前の@remore
9.
____
/⌒ ⌒\ /( ●) (●)\ /::::::⌒(__人__)⌒::::: \ 簡単だお! | |r┬-| | \ `ー'´ / 後に現実を知ることになります
10.
今日はTDDをケントベッ クのテスト駆動開発入門
で学んだ後、 僕の前に⽴ちはだかった いくつかの現実と、 僕がそれをどう乗り越え てきたかを紹介します
11.
※この物語は 割とノンフィ クションです
12.
@remoreについて • ニジボックスでソーシャルアプリ開発 • アジャイルな開発手法の導入を進めてる •
3か月前の自分: – TDDは実践経験なし • テスト駆動開発入門を読んだ知識だけ – PHPUnitのインストール方法と簡単な使い方 はネットで調べて知った程度
13.
TDD修行
TDD修行の旅 修行の ?????? | ■ ■■ レガシーコード山脈 レガシーコード山脈 ■■■ ▲▲▲▲▲ ▲ ▲ ????? ??????? ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲ ▲ ▲ ▲▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲ ▲ ▲ ▲ ▲ ▲ ▲▲ ▲ ▲▲ ▲ ▲▲ ▽スタート地点 スタート地点 ▲ ▲▲ ▲
14.
レガシーコード山脈 • テストコードのない実装が山のようにあ
る。 • 山の住⺠はソースコードの変更をした後、 周辺を含めて何も壊れていないことをき ちんと確認する。そのあとは、結果がう まくいくことを祈りながら暮らしている と言われている
15.
僕が登った山 • 自社MVCフレームワークを使ったソー
シャルアプリのレガシーコード • 言語はPHP • ソースコードは10万⾏ – フレームワーク部分を除いて、Model, Controller, Viewだけなら4000⾏くらい ※有効コード⾏数ベース • テストコード⾏数は0
16.
TDDつまづくあるある① レガシーコード(テストコードのな い実装)の山を目の当たりにして戦 意を喪失する。 (TDDをどのように現実の問題に適 用すればよいか、妙案が浮かばずに 途方に暮れている状態)
17.
あると思います (ありました)
18.
考え方:我流でGO 絶対的に正しいTDDの適用方法を知りたくなるのは人情だけど、多分状況は千 差万別なので、それを始めから⾒つけるのは困難。 失敗して傷つきながら自分なりのプラクティスを作っていく: •
MVCモデルでテストコードってどこから書けば良いのか – Model → Controller → Viewの順番でテストコードを書いていく方針でやってます • Controllerにかなりロジックがあって、テストできない部分が多い – これ、地味にかなりヘコみます・・「面倒くさっ」ってなる – まあ、Bad Designてことですよね。リファクタリングしないとね。Modelにテスト コード書き終わったらやろう。 – テストコードを書きながら、Modelにコードを移していくイメージ • Viewのテストコードはどうしようかな – 仕組み上難しい場合も多そう(viewの中でechoしてたりだとか) – @remoreの場合は、Viewにはテストコードを書いていない。(その代わりソース コードレビュー他の設計技法は適用)
19.
時間がかかりやすいところ •
Modelのコードだけテストしようとしたけど、フレームワークの初期化処 理を経由しないとModelに配置されてるオブジェクトを使えなかった – PHPUnitからModelを呼び出すために、テスティングフレームワーク内に、フレーム ワークの初期化処理だけを抜き出したphpスクリプトを新たに用意した • バッドノウハウでごめんなさい • テストを実⾏する度に、テストコードから呼び出したModelのメソッドに よってDBのレコードが変化していくので、何も考えないでテストを書いて いくと、直前に成功していたテストコードが通らなったりする – setUp()とtearDown()を活用して、どんな環境でも失敗しないフィクスチャを作る – 例: • setUp()で前回挿入したレコードを削除する • テストコード内で使用するユーザ情報も設定しておく – Datasetを比較するほど細かく内容をテストすることが現実的だと思えなかったので、 PHPUnitのデータベーステスト(PHPUnit/Extensions/Database/Testcase.php= DbUnitのポーティングを利用)はやらなかった – StubやMockは使っていない • 初めから使うことを想定して設計しておかないと使いづらい印象
20.
細かいけど書いておきたいこと • PHPUnitだと、1テストファイルに1テストクラス
(PHPUnit_Framework_TestCaseの継承)しか書けない(っぽ い) – テストファイルを”*Test.php”っていうファイル名にしておけば、 phpunitコマンド実⾏時にフォルダ名を渡すことでフォルダ内全体(ネ ストされているフォルダ含む)をテストしてくれる • コードの可読性を重視して、テスト関数名に日本語でテストの目的 を書いておくのがオススメ(文字コードはUTF-8であればテスト実 ⾏可能)
21.
TDD修行
TDD修行の旅 修行の 生産性の 生産性の谷 | ■ ■■ レガシーコード山脈 レガシーコード山脈 ■■■ ▲▲▲▲▲ ▲ ▲ ????? ??????? ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲ ▲ ▲ ▲▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲ ▲ ▲ ▲ ▲ ▲ ▲▲ ▲ ▲▲ ▲ ▲▲ ▽スタート地点 スタート地点 ▲ ▲▲ ▲
22.
生産性の谷 • レガシーコード山脈の難所の一つ • 谷には開発者の不安を取り除くことができ
る財宝が眠っていると言われている • 「テストコードは要らない。最速で実装を 終えよう。」という言い伝えを守り、山の 住人はこの谷には近づかずに生活している
23.
僕が落ちた谷 • 明らかに開発速度が落ちた –
この時期は「@remoreさん、今何してんすか?」と いうリーダーからの問いに答えるのが怖かった • 一時期、TDDから離れみたが、TDDをしないこと によって、テストコードが取り除いてくれていた 不安が確かにあったことに気付かされた • まあ、結局、開発速度が遅くなるのは自分が経験 不⾜なだけ
24.
TDDつまづくあるある② 思ったよりもテストコードを書くと 開発が遅くなって(なったように感 じて)しまい、戦意を喪失する。 (TDDをやった方がいいと頭ではわ かっていても、スキルが無いが為に テストコードを書かない方がローリ スクだと思い込んでしまう状態)
25.
あると思います (ありました)
26.
とにかく経験値を積む[書き方編] @remoreの場合、こんな経験を積んでいきました • 例題演習 –
ケントベックのテスト開発入門を写経したり • 三角形を判定する関数をTDDで書いたり • 演習問題と解答例をgithubに置いてます。 – https://github.com/remore/StudyTDD – FizzBuzz()をTDDで書いたり • 業務でレガシーコードにテストコードを追加した り • 新しく開発したツールやアプリにテストコードを 書いていったり
27.
とにかく経験値を積む[運用編] • 環境構築 –
Jenkinsのインストールを繰り返し⾏った – PhingやXdebugも使ってみた – PHPUnit以外のテスティングフレームワーク も試してみた • PEAR非依存のlimeやSimpleTestならインストー ルにつまづくこともなくてこちらもオススメ • 必要だった覚悟とか – 開発効率が下がったと思った分は残業してで も同じパフォーマンスを出すつもりでやる
28.
もがいているうちに 費用対効果について考え出した • テストコードは1メソッドに対して1テストするだけで
も違う – 「TDDは分析技法および設計技法」 – 1メソッドが無理なら、1つのクラスに対して1つテスト コードを書くだけでも全然違う • テストファーストをガリガリ回すのとは違っちゃうけど – 何が違うかというと、こんなことを確認させてくれる(テ スト駆動開発入門 p126より抜粋) • 機能はどこに所属するのか。既存のメソッドの修正なのか、既 存クラスの新規メソッドなのか、新しい場所に実装される既存 のメソッドなのか、新規クラスなのか。 • どのような名前をつけるべきなのか • 正しい答をどのようにチェックするのか • 正しい答えは何か • このテストから他のどのテストが提案されるのか
29.
費用対効果について
いま考えていること • 作成するテストのパターンとボリュームは柔軟に考えればよい – Kent Beckは「条件分岐、ループ、操作、多相性」の4つをテストする ことを推奨しているけどね – 無理にテストコードを追加しすぎると、テストコード地獄(書いても 書いても終わらない)にハマる – でも自分の中の不安は無視しちゃダメ • 例えば、デグレが頻出してる部分だけテストコードを書きながらリ ファクタリングしてみるとか – いきなり全部リファクタリングしようとしないこと。コードの量が⼤ きい場合は、十分に小さいサイズにリファクタすることで分割しなが らテストコードを追加していく。 • それとか、他の設計手法を交えることで割り切ることも時に有効 – 例:Viewのコードは不安が少ないからテストコードは書かずにソース コードレビューだけしておこう
30.
TDD修行
TDD修行の旅 修行の 生産性の 生産性の谷 | ■ ■■ レガシーコード山脈 レガシーコード山脈 ■■■ ▲▲▲▲▲ ▲ ▲ 自己満足の 自己満足の砦 ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲▲ ▲ ▲ ▲▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲ ▲ ▲ ▲ ▲ ▲ ▲▲ ▲ ▲▲ ▲ ▲▲ ▽スタート地点 スタート地点 ▲ ▲▲ ▲
31.
自己満足の砦 • 無関心と自信喪失に満ちた砦 • レガシーコード山脈を越えると⾒えてくる •
どんなに速くテストコードを書いても、テスト コードのおかげで潜在的なバグを修正できても、 複雑に作られた自己満足の砦を抜け出すことは困 難と言われている • テストコードが通らなくて時間をとられてしまい、 自信を失い、心が折れる旅人も多い
32.
意外に多くの勇者が一人で燃え尽 きてるんじゃないか説 •
自己満足という側面 – どんなに速くテストコードを書いても、 – テストコードのおかげで潜在的なバグを修正できても – 誰にも褒められない • 自信を失いやすいという側面 – テストコードが通らない時間は単純に苦痛 – テストが通らない(=レッド)まま数時間使ってしまった 時の無⼒感は異常 • 理想に燃えて始めたはずのTDD。その理想が仇になっ て、理想と現実のギャップがここでボディーブローの ようにきいてくる
33.
TDDつまづくあるある③ かけた努⼒の割に報われ難いように 思い込んでしまい、次第に戦意を喪 失していく。 (上手に説明しないと他人からは理 解されにくいことがままあって、や さぐれてるうちに次第に熱が冷めて 元のレガシーな頭に戻っていく)
34.
あると思います (ありました)
35.
アウトプットを心がける • 誰かに話す(共感してもらう) –
会社でTDDしててつまづいたら同僚に • そしてテストコードを追加したいと思ってくれるチームのリー ダーやメンバー、同僚、勉強会の皆さんに感謝を – プライベートの開発でつまづいたら勉強会で • というわけで、僕のここ数か月のつまづきをお話しさせても らって英気を養ってます。TDDBC in Tokyoの皆さんありがと うございます。 – 勉強会を主催しちゃうのも一つの手 • 成果を上手にアピールする – Assertを追加したテストコードをリポジトリにcommitす る時、堂々と”25Assert追加”のようにコメントに書く事 を習慣化する – 勉強会でLTさせてもらったりブログを書いて反響を頂いた り
36.
アウトプットする前に燃え尽きて しまいそうな時に読む精神論 • TDDはレッド、グリーン、リファクタリング
のリズムが⼤事。だけど、リズムが壊れたか らといって自分の能⼒が低いわけじゃないと 開き直れるかどうか。 • レッドの場合、自分が書いたコードに問題が ある場合が実際に多い。つまり、現実と向き 合えるかどうかが問われる。 • 問題を先延ばしにしない強い心を。 • 焦らないでOK。初めは時間がかかるものと 心得て、みんなで強い意志で取り組む。
37.
最近の僕のTDD使い方まとめ • レガシーコードと泥臭く戦う。 –
MVCならModelから少しずつ – Contorllerに残ってるコードはテストコードを書きながらリファクタリ ングしていく(=仕様化テストの導入) • 自分の経験不足を言い訳にしない – テストコードを書くと生産性が落ちるのは自分のせい – 書くテストコードの量は、1パターンでも書くと全然違う – TDDで戦うところとそうでないところ、割り切りも⼤事 • 一人で戦わない。仲間と戦う。 – 孤独との戦いもある – レッド、グリーン、リファクタリングのリズムが崩れてもファイティ ングポーズをとれるか。 – つらかったら話を聞いてもらうだけでも違う
38.
[付録] 読んでおくべきTDD関連の
ソース • 三周遅れのXP – http://www.slideshare.net/yoshiori/xp- 3242327 • 読んでおくべきテスト関係のTL – http://togetter.com/li/5878 – http://togetter.com/li/6759 – http://togetter.com/li/6923
Download now