TDD(テスト駆動開発)のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ(OmniGraffle)が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記2 このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
iOS/iPhone/iPad/MacOSX プログラミング, Objective-C, Cocoaなど 通知(Notification)を配信(POST)するメソッドのテストコードを考える。 ポイントは次の2つ (1) 意図したタイミングで通知が配信されたかどうか (2) 配信された通知は意図したものだったか たとえば addEntryWithInfo:tagName: というメソッドを呼び出すと LKQueueDidAddEntryNotification という通知が送られることをテストする場合を書いてみる。 テスト対象のメソッドの実装イメージはこんな感じ。 - (LKQueueEntry*)addEntryWithInfo:tagName: { : [[NSNotificationCenter defaultCenter] postNotificationName:LKQueueD
TDDのパターンに学習用テストというものがあると『テスト駆動開発入門』に載っていた。 自分が作ったものではない外部のライブラリを使い始めるときに、動作を確認するために小さなコードを書く、ということは誰でもしていることだと思うが、その動作確認のためのコードをテストとして書く。 それによりライブラリのAPIに対する理解をコードに落とし込んで残しておけるので、曖昧な理解が減りそう。 正しい理解ができていればテストはパスする。 またライブラリのバグなのか、自分の使い方が悪いのか切り分けるのにも使えそうだ。 そういう原因がよく分からない状況になってしまったらテストを追加して追い込んでいけば良い。 また副産物として、ライブラリがアップデートされたときにその影響をテストするのにも使うことができる。 試しにamazon-ecsで学習用のテストを書いてみた。 # -*- coding: utf-8 -*-
第1回2009/3/28(Sat) 第2回2009/5/9(Sat) 第3回2009/6/27(Sat) 第4回2009/8/1(Sat) 第5回2009/8/29(Sat)2009/9/6(日) 第6回2009/9/26(Sat)(予定)2009/10/4(Sun) 第7回2009/10/24(Sat)(予定)2009/11/14(土) 第8回2009/12/20(Sun) 第9回2010/2/13(Sat) スパム対策のため、ページ編集やコメント投稿時に認証が求められます。 認証ダイアログに表示されるユーザ名とパスワードを入力してください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く