【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
BDDについて自分なりにまとめてみた - ukstudio
BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振る舞いはそのクラスのメソッドとかの仕様になる。逆にユーザレベルの人が言う振る舞いはアプリケーションの要件・動作を言うだろう。 つま
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
テストを金額にするといくら？ ― ＠IT
テスト駆動開発（Test Driven Development：TDD）。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。 テスト駆動開発（TDD）とは テスト駆動開発は一般にエクストリーム・プログラミング（XP）の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なもの
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第17回リファクタリングをどこまでするか、いつやめるか 和田卓人 2007-12-25
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDDで「テストばかり書いて間に合うのか？」と質問されたときの正解 - きしだのHatena