Android、Java、Web系、Linux、マラソン等の備忘録

2014/01/12

テスト駆動開発講座の自分用メモ

0 件のコメント
下記サイトにはテスト駆動開発の動画の講座に加えて、動画の書き起こしがまとめてあります。

講座一覧

[動画で解説]和田卓人の“テスト駆動開発”講座:連載|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd

以下は僕が動画を見ながらメモしたものです。

視聴した講座

第6回 「写経」でTDDの手順や書き方を学ぶ:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0006

  • 学習方法
    • 写経
    • セミナー/ペアプロ

第7回 「経験者」からTDDのリズムを学ぶ ――セミナー,ペアプログラミング,レビュー,動画:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0007

  • 写経では得られない典型的なものの一つが「リズム」

第8回 テスト駆動開発の「サイクル」――まず受け入れテストで土台を作る:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0008

  • 受け入れテスト/機能テスト。まず、外側の視点から受け入れテストを書く
  • 例)ブラウザが,サーバに対してあるURLでGETアクセスをかけると,そのURLに対応したXMLを返すよ,というプログラム
    • サーバ側のプログラムがまったく存在しない状態
  • Selenium自体は,TDD的な無から有を生むようなアプローチというよりは,回帰テストとして使っていくのが良いのではないか

第9回 テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し,レッド,グリーンでサイクルを回す:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0009

  • 大きいテストを書く
    • そのテストを満たすために、実装するToDoを書いていく
    • 実装の段階を細かくしていく
    • 大きいテストはレッドのままだが、その中の細かい機能をレッド・グリーンのサイクルを回していく。その細かいのが全てグリーンになったら、大きいテストもグリーンになるというサイクル

第10回 テストの最小単位は不安:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0010

  • 上記の細かい機能のテストの最小単位は、不安という感情。
    • このコードは自信がある、または、以前書いたことがあるコードだと思うなら書かない
  • 学習テスト
    • 暗記できていないメソッドの使い方、よくわかっていない使い方についてテストしながら理解する
    • 例えば、正規表現によるパターンマッチ。いきなり機能の実装を書き始めるのではなくて、パターンマッチのライブラリの使い方を理解しながらテストを書く事も
    • テストコードの中で試しに実装していたものを、リファクタリングで育ててつつ、プロダクトコードへというようなやり方も

第11回 テストの資産価値:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0011

  • 最初に大きなテストを書いて失敗させる
    • 例)アプリ起動後に初期化処理が実行される。その結果をテストするコードを書く
  • これを成功させるために、小さいテストを書いて開発を進める
    • 例)初期化処理を構成する細かいメソッドのテストを書く
  • 開発を進めた結果、最初の大きなテストが成功する
  • その後仕様変更等が行われた場合、小さいテストの結果が真っ赤になり、メンテナンスが他変になる場合がある
  • 小さいテスト群と大きいテストは資産価値が同じと考えて良いのではないか。メンテナンスが大変なら小さいテスト群は削除してしまってよいのでは
  • 不安が残る部分は残しておいた方がいいと思う

第12回 モックオブジェクト技法:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0012

  • モック:仕様のシミュレート
  • 開発中のクラスAがあり、別チームが開発しているまたは、まだ開発されていないクラスB,Cがある場合は、クラスB,Cの偽物(モックオブジェクト)を作ってシミュレートしてクラスAをテストする
  • その後、本物のクラスB,Cが出来上がったら、A,B,Cを結合してテストし成功させる
  • ある日、クラスCに仕様変更が発生する。この場合のテストの修正は?
    • A,B,Cを結合した時のテストは当然仕様変更に伴い修正し、テストを成功させる
    • モックオブジェクトのメンテナンスは、本物を結合してテストが通っているのなら、メンテナンスの大変さがありテストとしてそんなに資産価値がないので捨ててしまって良いのでは?

第13回 私のTDDへの目覚め:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0013

  • TDDに対して「これは!」と思ったタイミングは?
    • 今まで単純なバグが多かった
    • ケントベックの本を写経してみた
    • プログラミング能力の底上げに使えるんじゃないかという体験

第14回 テスト厨,TDDの壁,DBやGUIのテスト:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0014

  • TDDの壁:テスト駆動でできることとできないことの存在
    • DBや画面を伴うテストは割に合わない
  • テスト厨:なんでもテストでかけるという熱中状態
    • テストの資産価値として割に合わないものもテストを書いてしまう
  • 壁を越えると
    • 割に合わなかったものをツールにまかせて、資産価値のあるものをテストを書けるようになる
    • 画面は目でテストして、画面とは離した部分でテスト書けないかと考えられるようになる

第15回 追い込まれたときのテスト:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0015

  • 「追い込まれている」というのが理由で,テストをさぼることはありますか?
    • 小さいテストを少なめにしてコードを書いたこともあった
    • 逆に追い込まれたときに、動作確認の足場として集中してテストの足場を作ったという例も

第16回 プログラミング言語とTDDは,どちらを先にマスターすべきか?:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0016

  • 言語をマスターするためにTDDを使うような使い方も→学習テスト

第17回 リファクタリングをどこまでするか,いつやめるか:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0017

  • リファクタリングはどこまで?
    • 重複がなくなるまで。DRY(Don't repeat yourself)
    • モヤモヤがなくなったら

第18回 公布済みインタフェースのリファクタリング:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0018

  • Publish(ed)インタフェース:Web APIのような。なかなか好きに触れないインタフェース
    • リファクタリングではいきなり廃止しないで、非推奨にして残しつつ新しいインタフェースを追加する。移行期間を設けてしかるべき時期がきたら廃止するような運用

第19回 チーム開発での規約・規律:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0019

  • 他の人のテストが読めないってことが起ってくるので、規約(テストの書き方の均一性を保つためのもの)を決めるのは重要になってくることも

第20回 テストコードの重複はアリかナシか:[動画で解説]和田卓人の“テスト駆動開発”講座|gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/tdd/0020

  • プロダクトコードは重複がないのが理想
  • テストコードは2つの指針
    • ある程度重複があってもいいから何をやってのかわかるようにとする指針
    • プロダクトコードのように重複がないのが理想とする指針
  • 達人プログラマー(Andrew Hunt/David Thomas(著))「テストコードに重複はあってはならない」
  • 和田さん「重複はアリ」
  • テストのリファクタリングの話は次回(?)以降
2015/08/08 一部修正

0 件のコメント :

コメントを投稿