8. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 3か月前の@remore 9. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 後に現実を知ることになります
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
8. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 3か月前の@remore 9. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 後に現実を知ることになります
テスト駆動開発チートシート - やさしいデスマーチ
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経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
TDDについて考えてみた事を書いてみる - はてっちょ
TDD久々に流行りのトピックについて書いてみようかと思うので、書いてみる。まぁ、あまり客観的ではない、主観的にこうおもいます、っていういつもの雑記ですよ、ええ。TDDが品質保証の手段とか、テスト手法とか、そういう議論が活発なのだけど、俺としては、こいつらはテストを自動化することによって、副次的に発生することではないか、そう思っている。JUnitTDDの名前を一躍有名にしたのはJUnitだと思っているのだけど、じゃぁ、TDDのコンセプトは何だろう、と言う事を考えてみると「動かないテスト（紙に書いて印刷したテストメトリックスであるとか）よりも動くテスト（実行すれば動く「プログラムとして書いたテスト」）」に尽きる、と思うわけで、そこからこういう風に展開した結果として「TDD」が生まれたんじゃないかな、と思っている「テストをプログラムとして書いたことで、テストをやる、と言う点でコスト（時間や人的資
テスト駆動開発のパターン・Test List（テストリスト） - Strategic Choice
Q：何をテストすべきなのか。A：開始する前に、作成する必要があると思われるすべてのテストのリストを書く。どうして？プログラミングのストレスへ対処しようとしても、目的地がわからなければ１歩も進みません。プログラミングを開始する際は、何を達成しようとしているかを明確にします。一般論として、達成しようとしていることを追跡する戦略の１つは、これらをすべて「頭の中」に保持する方法です。しかし、これは悪循環に陥ります。蓄積した経験が増加すると、実行すべきだと認識することが増加する。実行すべきことが増加すると、現在実行中のことへの注意が減少する。現在実行中のことへの注意が減少すると、達成することが減少する。達成することが減少すると、実行すべきことが増加する。気まぐれにプログラミングするだけでは、この悪循環は壊れません。どうすれば？達成しようとすることをリストに書き出します。次の数時間で達成したいこと、そ
最近の TDD 議論についてちゃんと僕の気持ちを書いてみる - 宇宙行きたい
最初に ちょっと最近，ドタバタしてて twitter だと腰を据えて話せないなと感じたので，ちょっと最近のTDD 議論についてちゃんと僕の気持ちを書いてみようと思います． これは僕が"今"感じてる事とか考えている事を書いているだけですので，誰かを論破したいとか，誰かを説得したいという意思は無いです． 本当に裏とかはなく，純粋に「"庄司嘉織"という人間は"今この時"にこういう事を感じてこういう事を考えた」というだけです． もちろん明日には考えが変わるかもしれないし，逆に過去の発言とは違うかもしれませんが，「最近はこう感じている」という事をちゃんと書いておこうと思いました． デブサミでの発表について id:babie さんにちゃんと返事をしていなかったので，まずちゃんと返事をしておこうと思います．(遅くなってしまってすいません) @kakutani は興味なくても、あのスライドだと @yosh
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
