テスト駆動開発の効果はどのくらいある？
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。 そして、BootCamp と日常を重ねて思ったことなど。 大変だ！ レガシーコードの修正だ！TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。 そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。 対象はいわゆるMVCフレームワークを利用したWebアプリ最速でやってくれ（ここがもう「なんだかな」ではあるんだが）変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ できるだけここはいじりたくないいやぁ、レガシーだねぇ。 どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだなんか censor のない Camp ネタのように見えるなこの部分だけ切り出
TDD Boot Camp 北陸に行ってきたんですよ - rch850 の上澄み
被らないようにタイトル考えるのも大変ですね。TDD Boot Camp 北陸に行ってまいりました。 三本柱 バージョン管理 テスティング 自動化 「三種の神器」だと、どれかが欠けても大丈夫そう。深刻さが足りない。 書籍紹介ラッシュ だいたい有名どころですが、あらためて。 Emergent Design: The Evolutionary Nature of Professional Software Development (Net Objectives Lean-Agile Series) 創発的設計を為すピラミッド。ベースにあるのはコードの質。 達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化 (Ascii software engineering series) 黒より白！アスキーから出ている方に上記の三本柱について書かれています 以下三冊
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
RspecとCucumberでTDD/BDDを極める (The Rspec Bookの紹介) - Masatomo Nakano Blog
本の紹介第2弾。少し前、Twitter上でTDD/BDDについて盛り上がっていたので、この本を紹介してみたくなった。 「The Rspec Book: Behaviour Driven Development With Rspec, Cucumber, and Friends」という本。 この本は、RspecとCucumberを使い、どう考え、どうシステムを作っていくか、というをチュートリアルを交えながら紹介する構成になっている。 ただUnit Testを紹介するだけではなく、Unit TestツールであるRspecに、BDDツールであるCucumberを組み合わせて使うことで、Unit Testでカバーできない部分をCucumberで補い開発をする、というところがこの本の肝になっている。 この本を読み、実践することで、Unit Test*だけ*を書いてシステムを作っているときのモヤモヤ感
深夜のテストTL
ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13
TDDを理解するためのまとめ - Logic Dice
わんくま同盟名古屋勉強会#9に置いて、biacさんのTDDに関する話が出たので、少し自分がTDDについて思うことを纏めてみました。 TDDが説明されるのを聞く度、見る度、多分説明している本人は分かっているのだろうけれど、それが他の人に本当に伝わっているのかが怪しいと思ったためです。 というのも、自分が（多分）理解するまでに、酷い回り道をしたもので。 また、biacさんのTDDに関するWebサイトはこちら。 TDD.NET - http://www.tdd-net.jp/ 以下、長文注意。 背景 まず、自分がTDD(より正確に記述するなら、「テストファースト*1」が正しく、TDDではない)をまともに実践しようと思って始めたのが、大学の4年時の最初なので、今から18ヶ月程度前です。 とある研究室のプロジェクトで使いたいという話になり、そこで実践を行いました。当時の環境はJDK + JUnitで
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
RedmineとHudsonの関係付け - プログラマの思索
Redmineのチケットとバージョン管理を連携できる機能は、変更管理のインフラを提供してくれる。 変更管理について考えたメモ書き。 【元ネタ】 PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス） 【1】変更管理が必要な場面 SEと呼ばれる人の仕事を眺めてみると、要件や仕様に関する変更管理プロセスに従事している時が多いことに気付く。 SEの一番の仕事は、顧客から要件を聞き取り、仕様書としてまとめて、開発者へ仕様を提示する。 つまり、業務のインターフェイスを設計すること。 設計工程で完璧な仕様書が作られる可能性は低い。 むしろ、要件漏れ、設計漏れが開発や結合テスト、あるいは受入テストで大きなリスクとして発覚することが多い。 昨今のシステム開発では、SeasarやRailsのような優れたフレームワークがあり、JUnitのようなテストユニットがあるので、単体テストをクリア
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
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)
Unit Testの書き順(1)
私が概ね全てのお仕事コードにUnit Testをつけるようになって、だいたい3年になります。 Testabilityという物に高い意識を持つようになった期間とだいたい一致している為、Unit Testを書くという事自体のキャリアもまだ3年です。 プログラムを書くという事だともうすぐ10年になりますが、Unit Testはようやく素人の域を脱した程度の所です。 まだまだそんなレベルではありますが、それでも3年続ければ3年続けただけの物もあります。 その一つとして、Unit Testの書き順という考え方があります。 Unit Testを書く時に、最初に何から書くでしょうか？ 私は expectedの変数 inputの変数 その他 という風に書きます。1と2は入れ替わる事もあります。例を挙げましょう。 function Adder() { return {add: function(a, b)
「実演テスト駆動開発」 WEB+DB PRESS Vol.35特集 特設サイト
WEB+DB PRESS Vol.35の特集1「実演！テスト駆動開発」の特設ページです．テスト駆動開発（TDD）の実演ムービーや誌面サポート情報などを掲載しています． 更新履歴 2006年10月24日 実演ムービーの追加 タスク2「サーブレットのアクセスURLからDAOの名前を抽出する」の実演ムービー3本を追加しました． 環境構築ムービーの追加 Subversion環境の構築ムービー3本を追加しました． 補足情報の追加・変更 第2章～第8章の各章終了時点でのサンプルコードを公開しました．また，すでに公開済みだった第8章完全版のコードも差し替えましたので，お手数ですが再度ダウンロードしてください． 補足情報の追加 「テストフィルタ機能，受け入れテスト実行の自動化機能について」を追加しました． 補足情報の追加 「著者のEclipseテンプレートを公開！」を追加しました． 誌面訂正情報の掲載 第
TDDとテストファースト => TDDのオレオレ定義と5回リロードルール - moroの日記
自分でももやもやしてるのでツッコミ希望。 考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/ TDDを紹介するときに、「TDDではプロダクトコードの前にテストを書く」という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。 TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。 別にあとから作っても*1、 自分が作ってるモジュールを使ってみたら、APIが「ねーよwww」くらい使いづらいものであると気づいたり、とか
C++アプリケーションの効率的なテスト手法（CppUnit編） ― ＠IT
第2回 C++アプリケーションの効率的なテスト手法（CppUnit編）：連載 C++開発者のための単体テスト入門（1/4 ページ） 連載目次 前回は単体テストの重要性を示し、従来のC／C++でのテスト手法であるprintf関数やassertマクロを使ったテストを紹介しました。この2つのテスト手法は開発環境（コンパイラとライブラリ）さえあれば利用でき、その使い方も簡単です。しかしながら、いずれも系統立てて、効率よくテストを行うには力不足の感が否めません。 今回は、Visual C++ 2005 Express Editionを含むVisual Studio 2005（以後、VS 2005）で利用できる代表的な単体テスト・フレームワーク（Unit Test Framework）の1つである「CppUnit」を紹介します。 ■単体テスト・フレームワークとは？ 前回、「バグは早期発見が望ましい。早
gihyo.jpにて連載させていただいたテスト駆動開発のWeb連載もとうとう最終回を迎えました - t-wadaの日記
http://gihyo.jp/dev/serial/01/tdd/ 技術評論社様の情報サイト「gihyo.jp」にて、動画と連動した連載のかたちとして書かせていただいた今回のWeb連載も、ついに連載終了の日を迎えました。一応公約通り年内で連載終了まで来ましたね。お読みくださった方々には本当に感謝いたします。ありがとうございました。 ここで連載の全記事に、リンクを張っておきます 第1回 連載を始めるにあたって 2007年10月26日 第2回 「テスト駆動開発」とは何か？ 2007年10月30日 第3回 「テスト」という言葉について ── Developer Testing，Customer Testing，QA Testing 2007年11月2日 第4回 ナントカテスト ―― ユニットテスト，単体テスト，機能テスト，結合テスト，受け入れテスト 2007年11月6日 第5回 進捗管理として
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
