メモがあったので乗っけとく
TDDBC TOKYO
twada和田拓人
gihyo.jp
動作する綺麗なコード…
動くー綺麗か?
②つの道がある。
1.汚い・動かない→※②汚い・動く→綺麗・動く
2.汚い・動かない→※①綺麗・動かない→綺麗・動く
※①綺麗さには限界がないので、期限に間に合わなくなる。
完璧主義沼地。
ソフトウェア開発手法はまだまだ未熟。
→動かして初めて分かることのほうが多い。
※②堕落沼に落ちる。
コードを綺麗にすることを怠ってはいけない。
2.のほうがTDD。
TDDとは?
目標を考える(TODOリスト。設計リストを作成。)
作業を選択する。
RED,GREEN,REFACTORのサイクルを回す。
→つまり2.のサイクルを繰り返す。
何をしてるのかを常に意識することがアジャイルでは大事!
矢印があるということは目的がひとつということ。
GREEN…取りあえず動くコードを書く。【汚くていい】。
Refactoring…小さいうちに片付ける。
リーダブルコード、リファクタリングの有名なやつ
2冊本がおすすめ。
大事なこと1.
大きい問題をそのままテストするのではなく、
小さい問題に分けて、それを組み合わせて
大きい問題を解くようにする。
大事なこと2.
サイクルを素早く、回数を行う。
大事なこと3.
自分が最初のユーザである
(自分が作るものをまず初めに自分が使う。)
→テストコードで使う。
大事なこと4.
【不安なこと】をテストする。
→不安でないことはテストしない。
getter,setterにはいらんでしょ?
TDDのメリット
ソフトウェア工学的なメリッドもあるが、最大の理由は
【心理的なもの】【健康】
→即座にフィードバックが得られる
→書いたコードに自信をもつため
→これから書くコードに自信をもつため
健康なら毎日REDBULL+終電ダッシュはしなくていい。
TDD採用(MS,IBMの例)
管理者見積もりによる増加コード実装時間
15%~35%
テストコードはプロダクトコードの30%〜90%
コーディング行・時間は増えるが、
デバッグの時間が減るので全体の時間は減る。
デバッグにかかる時間はブレが大きいが、
そのブレを抑える働きがある。
TDD応用
テストのないコードがたくさんある…
レガシーコード改善ガイド本
すでにデータの入ったデータベースがある…
データベースリファクタリング本
SlowTests…
メモリに対するテストより、DB、ネットワークに対する
テストのほうが時間がかかる。
→フィードバックにかかる時間が増えてしまう。
xUnitTestPatterns本…英語
ネットのwikiをまとめたもの。
テストをどこまで行えばよいか・何をテストすればよいか…
ソフトウェアテスト技法ドリル本
実際の複雑なテストをどう行うか?
実践テスト駆動開発
TDDはスキル!
才能ではなく習得可能!
量は質に変化する!
写経!!
**********************
実践テスト駆動開発の著者の一人
スティーブフリーマン(Steve Freeman)
新しい機能を追加するのではなく
既存の機能をリファクタリングすだけなら
リファクタリング用のテストコードを書いて、
リファクタリングを行う?
●テストダブルを行う理由は?
オブジェクト間のメッセージが飛びかっていて、
(オブジェクトが頂点でメッセージが辺のようなグラフ)
その中のやり取りが上手くフィットしているか
確認するってのが10年前に言われて、
今もそれが目的だと思っている。
テストを細かくするため。
たくさんエラーが出た時にどれが問題かを判断するため。
●不可能なテストをどのように対応するか?
→レガシーコード改善ガイド本見て。
依存関係を切っていく。
大きな塊でやっていく。
小さく取り出して安全な形で変えていく(リファクタリング?)
そのうち状況が変わったり、
解決につながるアイディアが思い浮かぶ。
0 件のコメント:
コメントを投稿