【翻訳】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
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
より良いテスト駆動開発を行うためのチートシートの紹介
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト | Act as Professional
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか？p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。 そして、BootCamp と日常を重ねて思ったことなど。 大変だ！ レガシーコードの修正だ！TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。 そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。 対象はいわゆるMVCフレームワークを利用したWebアプリ最速でやってくれ（ここがもう「なんだかな」ではあるんだが）変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ できるだけここはいじりたくないいやぁ、レガシーだねぇ。 どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだなんか censor のない Camp ネタのように見えるなこの部分だけ切り出
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
TDDを行うとソフトウェアの信頼度が上がる理由 - babie, you're my home
「TDDはテスト手法か否か」の議論で、いまいち私の考えが伝えきれてないようでした(link1, link2)ので、表題にあることを通じて、私のTDDに対する理解の説明を試みます。 用語説明 本題に入る前にこれから使う用語を説明しておきます。 科学的方法には、伝統的な方法としてベーコン由来の実証主義、割と最近のポパー由来の反証主義があります。それぞれ批判はあるのですが、２大潮流といって差し支えないと思います（私は科学哲学については勉強中であり近年の研究はフォローしてないこと、また、観点が反証主義よりなことを、お断りしておきます）。 ここでは、 実証主義……実証の積み重ねから信頼度の高い理論が導けるとする態度 反証主義……様々な反証テストに耐えた理論が信頼度が高いとみなす態度 とします。 先の用語に出てきた、実証、反証とは、 実証……ある理論を経験や実験から真であると証明すること 反証……ある
TDDは品質担保のためでは無い？
TechnicalTDD談義への反応に対する雑感 - 千里霧中 自分はTDDすらやったことの無い、ある意味時代遅れの開発しかやったことはないのだけど、先のエントリを読むとTDDのテストと単体テストは別物という解釈らしい。 それを聞いたとき、「？」と思ったのが本音だ。テストコードなのに品質とは関係ないのだろうか？と。 TDDに対する私なりの解釈 私はある関数のコードを書くときにJavadocやDoxygenで関数ヘッ... TDD談義への反応に対する雑感 - 千里霧中 自分はTDDすらやったことの無い、ある意味時代遅れの開発しかやったことはないのだけど、先のエントリを読むとTDDのテストと単体テストは別物という解釈らしい。 それを聞いたとき、「？」と思ったのが本音だ。テストコードなのに品質とは関係ないのだろうか？と。 TDDに対する私なりの解釈 私はある関数のコードを書くときにJavadoc
最近の TDD 議論についてちゃんと僕の気持ちを書いてみる - 宇宙行きたい
最初に ちょっと最近，ドタバタしてて twitter だと腰を据えて話せないなと感じたので，ちょっと最近のTDD 議論についてちゃんと僕の気持ちを書いてみようと思います． これは僕が"今"感じてる事とか考えている事を書いているだけですので，誰かを論破したいとか，誰かを説得したいという意思は無いです． 本当に裏とかはなく，純粋に「"庄司嘉織"という人間は"今この時"にこういう事を感じてこういう事を考えた」というだけです． もちろん明日には考えが変わるかもしれないし，逆に過去の発言とは違うかもしれませんが，「最近はこう感じている」という事をちゃんと書いておこうと思いました． デブサミでの発表について id:babie さんにちゃんと返事をしていなかったので，まずちゃんと返事をしておこうと思います．(遅くなってしまってすいません) @kakutani は興味なくても、あのスライドだと @yosh
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
TDDはテスト手法か否か
なんもわからん @babie TDDは論理実証主義的な面が強調されすぎたために、BDDなどという言い換えが行われた。反証主義的に、エラーを積極的に起こそうとするテストを書くべき。 2010-02-21 13:45:09
デブサミ2010 - すがブロ
二日目だけ、参加してきました 強く印象に残ったところだけ書きます。 当日の発表資料は下記にどんどん追加されていくようです*1。 404 error. Page Not Found. 【19-B-3】三周遅れのXP -僕とドワンゴのXP- id:Yoshiori さんのTDDの話。個人的に一番刺さったのはこの発表でした。 タイトルについて 1週目はケントベックが道を作った 2週目は角谷さんたちが道を広めた そして今僕たちは三週目（だから正確にはタイトルは間違っていて、二週遅れ） 3週目の僕たちは高速道路を作る 「XPの4つの価値」を実現するための方法 コミュニケーション（チームで気軽にコミュニケーションできるように"おやつ神社"というのがある） シンプルさ フィードバック 勇気 TDDとは（極端に言えば） 開発手法であって、テスト手法ではない リファクタリングできれいなコードにしていくための
深夜のテストTL
ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13
TDDでアーキテクチャを導出出来るか - カタチづくり
この対談、面白い！必見ですよ、必見。 概要 JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。TDDと契約による設計(Design by Contract)の比較や、システムとビジネスドメインモデルを調和させるためには、事前にどれくらいのアーキテクチャ設計をしておかなければならないのか、などが議論されている。（翻訳：近藤 修平 - (株)永和システムマネジメント） Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。 見ながら思ったことをメモ。思考が色んなところに飛び火したので、対談の内容とはあまり関係ないことも
TDD Boot Camp 北陸 事前アンケート中間発表 - @katzchang.contexts
自由回答欄がいい感じにいい感じなので、だーっとコピペします。 引き続き、このアンケートにご協力頂けるかたを募集しています。TDDBC北陸に参加してみたい方はもちろん、興味はあるけど参加はできなさそうな方なども、ぜひご協力ください。 アンケートは => http://bit.ly/6ToL7W イベントの参加募集は、1/12くらいから始める予定です。参加表明っぽい設問がありますが、改めて募集しますので、今しばらくお待ちください。顔。 あなたが自動テストを使って開発しているなかで、課題となっていることがあれば、教えてください。 TDDを既に実践している テストの資産価値。今後役に立たない/足枷となるテストをいかに捨てるか。 スローテスト。 テストしにくいもののテスト。JavaScript や GUI など。 「テスト」という用語がもたらす誤解。お客様には品質保証として捉えられがち。都度説明して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD について
三周遅れのXP
Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。
BPStudy#29 まとめ
