More Related Content
Similar to TDD & Pull Request入門 (20)
TDD & Pull Request入門
- 24. TODO
- 誕生
- 生存
先にテストを書いて失敗を確認する
タスクに着手したら
24
➤ 問題を実行可能なテストで明確にするため
(何が実行できたら問題を解いたと言える?)
➤ テスト対象のメソッドの使い方例を明瞭にするため
(クラスやメソッドを利用する人はどう使えると嬉しいだろうか?)
➤ テストが期待通り動作していることを確認するため
➤ 後日にまとめてテストでは、テストが記述が難しい実装に
なってしまうため
(testでassertが書けるように実装するにはどうすればよいだろうか?)
※問題を解く前に問題を明瞭にするのは、問題を解くときのの基本鉄則。テストで表現するのがポイント
※ただしテストファーストに慣れずに手が止まってしまうなら、TDDの制約をゆるめ、“ちょっと実装したら直ぐテストで確認
(つまり何の問題を解いてたのか?をテストで明瞭にしてみよう)”で始めるがオススメ
- 43. オススメのTDDの自習・学習
➤ TDD本、Rails Tutorialを写経
(真似てタイプして著者の追体験する)
➤ 練習お題を繰り返し解く
プログラミングの学習法として、Code Kata 、「写経」、「練習、練習、
練習」などが知られているが TDDも練習が必要
- http://d.hatena.ne.jp/absj31/20120721/1342880403
- http://devtesting.jp/tddbc/?TDDBC%E4%BB%99%E5%8F%B003%2F%E8%AA%B2%E9%A1
%8C
➤ 同じ学生仲間で集まってチャレンジして、意見交換する
➤ TDDBCや Coderetreat などのプログラミングを学ぶイ
ベントに参加。自分よりうまい人から教わる
http://devtesting.jp/tddbc/
➤ パターンなど一般的な設計の本を読む。ネットで調べる
43
- 46. Pull Request とは?
➤“プルリクエストは、Bitbucket を使った
開発者のコラボレーションを促進する機
能の 1 つです。使いやすい Web イン
ターフェイスで、提案された変更を公式
プロジェクトに統合する前に議論するこ
とができます。”
https://www.atlassian.com/ja/git/workflows#!pull-request
46
Editor's Notes
- 「読めない」
「変更箇所が分散して影響範囲が読めない。。。」
「修正して壊したらどうしよう」
- ”目標値”と”実際の値”を比較して 値が一致するまで調整する仕組み.運転の際は、人が目の前を見て、安全に(車間距離とるや歩道に乗り上げずに)
目的地: 箱根、なんで箱根? 家族で温泉旅行を楽しみたい!
前日に箱根が大雨で行くのが微妙。じゃ代わりに、群馬の温泉にしようか。
- 顧客が ビジネスのハンドルを握って
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 大きな問題を小さな問題に分割してステップバイステップでとくことが大事
- 動作する= ユーザにとって役立つ、使える。目的を果たせる.市場にフィットしたプロダクト
きれいな= 未来のめんテナーにとって修正できる、障害があってもすぐに解析して直せる
動作するきれいなコードを目標に実現する方法はTDDだけではない
- テストとともにリファクタリングできれいなコードを作れる。
外側のAcceptance Testing では、テストを対話に使って何を作ればよいかを明らかにできる。
内部の実装している段階で、エッジケースのAcceptance Testのパターンも発見することがあるでしょう。
- 問題(満たすべき仕様)を理解するため
- あとからの異常系は肉付け出来る傾向がある。
- その他テストが期待通り動作していることを確認するため
- 例えば、「コーディング規約が守っているだろうか?」
例えば、「テストコードみて使われ方のAPIが本当に良いだろうか? Command/Queryの分離の原則からができないだろうか?名前は適切だろうか?」
例えば、「本当に良いだろうか? テスト対象とのコラボレーション要素数が多すぎないだろうか?」
例えば、「メソッドの長さはどうだろうか?」「引数の数は?」
例えば、「関数型にならい副作用のないメソッドで記述できないだろうか?」
例えば、「数値や二次元配列の基本データ型に執着していないだろうか?」
例えば、「他の人が読んで理解するまでの時間は短いといえるだろうか?」
例えば、「メソッド名やクラス名はわかりやすいだろうか?」
- (おめでとう!)
- (おめでとう!)
- (TDD自体は多数のコードや設計の良し悪しの判断と改善するタイミングは提供するが、良いコードや設計判断の良し悪しについては深く語っていない)
- 2年目の若手が、先輩のPRを読んで参考にしている。
(作業や議論のログが残るってのが、コメントで「ちょめちょめのライブラリーがあるよ。」「○◎気をつけなきゃね」ってのは読んで
「あ、ここは気をつけなきゃ」「っx書くのがスタンダードなんだ」って)
- ヒントは、TDD、Pull Requestのなかに
“問題Aは解く価値のある問題?解き方Aは妥当な解き方?”