テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
テスト駆動開発 - Wikipedia
テスト駆動開発 (てすとくどうかいはつ、英: test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年[いつ?]はビヘイビア駆動開発へと発展を遂げている。 最も基本となる開発サイクルは以下のようになる。 失敗するテストを書く できる限り早く、テストに通るような最小限のコードを書く コードの重複を除去する（リファクタリング） なお、テストの実行環境ツールであるxUnitでは、テストの失敗を赤いバー、成功を緑のバーで通知するため、上記のサイクルは R
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
TDD Boot Camp 横浜で初めてGroovy触ったらかっこよすぎﾜﾛﾀwwww #tddbc - (カチャカチャカチャ…) (ッターン！)
1日たってしまいましたが、11/06にTDD Boot Camp 横浜に参加してきました。詳しい記事は、id:absj31さんの記事が素晴らしくまとまっているので、ご覧くださいませ。 TDD Boot Camp 横浜に参加してきた #tddbc - Diary of absj31 TDD BCの感想と、Groovyを初めて触った感想です Groovyペアに立候補した理由 「募集」をしているわけで、立候補すれば、その場でペア成立 Groovyを触ったことがなくても大丈夫という前提 プログラミング言語好きとしては、Groovy触ってみたかった 普通なら、師匠は直々に、言語のフォースを教えくれない 運営の方と、TDDやったほうが身につきそう！ たしか、こんな理由だったと思います。打算と興味が五分五分といったところでしょうか。運営の方が、Groovy本を持ってきてくれて、 パラパラと見た第一印象は
テスト駆動開発入門ネクストステップ
テスト駆動開発入門ネクストステップ 1. テスト駆動開発入門 ネクストステップ 井芹洋輝 TDD Boot Camp 東京 for C++ 2011/10/8 @国立情報学研究所 2. 謝辞 • 主催の今給黎さん • 和田さん、会場提供、スタッフの方々 • 参加者の皆さま 深くお礼申しあげます 3. 自己紹介 • 井芹 洋輝(@goyoki/id:goyoki) • 組み込みエンジニア • WACATE実行委員/TDD研究会 • 講演/執筆： – XP祭り関西「ユニットテストの保守性を作りこむ」 – Androidテスト祭り「テストの活用による開発効率化」 – 並カン「FPGA/HDLを活用したソフトウェア並列処理の構築」等 4. 概要 本講義はTDDの基本サイクルを学んだ方 が対象です。 本講義ではTDDを開発で実践するための 知識、TDDについて自立して学習を進め るための情報を学び、
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)
テスト駆動開発が嫌いだ - きしだのHatena
テスト駆動開発が嫌いだ。 ただし、ここでの「テスト駆動開発」は日本で今TDDと呼ばれてる多義的なものじゃなく、「テスト駆動開発入門」にかかれている「テスト駆動開発」。 もっと正確にいうと「テスト駆動開発入門」がミスリーディングをわざと誘ってて有害で嫌い。 テストは、プログラムが正しく動くことは検証できるけど、プログラムが正しいことは検証できない。そのようなテストに設計を依存してしまうと、正しく動くプログラムは作れるけど正しいプログラムは作れない。 設計も含めてテストによって駆動しましょうという「テスト駆動開発入門」のやり方では正しいプログラムが作れない。プログラムの正しさを別のやり方で担保しつつ、そちらを中心に開発を駆動して、あくまでも開発作業だけをテストで駆動するという考え方のほうが、正しいプログラムに近づける。 そして、TDDをいまがんばってる人たちも、それは当たり前にわかってると思う
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
8. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 3か月前の@remore 9. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 後に現実を知ることになります
BDDについて自分なりにまとめてみた - UKSTUDIO
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
Scrum Alliance - My Experiments with TDD
I started my IT journey as a coder, although I was called a developer. I worked on small and medium-sized software projects and products, and for the first few years I put most of my effort into writing code and implementing required functionality. I tried my best, of course, but usually I faced a hard time during production and after QA releases. As a result, I started stretching my working hours
三角形問題ではKent Beckにも見落としがあった! - A Lifelong Software Tester (生涯一テスター)
みなさんは三角形問題に対していくつのテストケースがつくれたでしょうか? Myersの当時の調査では「高度な経験をもつ専門プログラマの平均点数は14点満点でたった7.8点」だったそうです。みなさんも、Hammingが言うところの三角形問題の「隠れた前提(hidden assumption)」を見落として「よくできる学生でも(3,4,7)の組が不等辺三角形と呼ぶべきでないことを見い出して驚く(Gruenberger)」のと同じ状況になりませんでしたか? もしそうだったとしてもがっかりすることはありません。 実はKent Beckですらこの見落としがあったのです。 前回の「三角形問題で必要なテストケース数」で、Kent Beckが「テスト駆動開発入門」の中で6個で十分と書いていることを紹介しましたが、この部分の記述は2001年12月のUSENETニュースグループcomp.lang.rubyで議論
TDD(テスト駆動開発)をはじめたい人にオススメの資料(無料) | Act as Professional
TDDBC in TokyoをPHPUnitでやる予定なので、TDD関連資料をあさってました。 実際に手を動かして、1から2時間で最後までやり通せるTDDの資料を見つけました。 TDDに興味を持った方が最初にやるのにちょうど良い内容なので、お知らせします。 オブラブで公開されている車窓からのTDDです。Java+JUnitの構成で書かれていますが、PHP+PHPUnitで、ほとんどPHPっぽく書き直せば問題なくTDDの雰囲気を学べる内容です。 Fake It 三角測量 リファクタリング などのタイミングを具体的に理解できるストーリー仕立てになっています。内容のボリュームもお手軽なので、TDDに興味のある方は、やってみてはいかがでしょうか？TDDの良さが体験できると思います。 PHPのコードをgithubで公開しています。「PHPでどう書くの？」って思った方は参考にしてください。
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
テストファーストの弊害
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
テスト駆動開発チートシート - やさしいデスマーチ
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でもたぶん作れると思います。
より良いテスト駆動開発を行うためのチートシートの紹介
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
The only one big thing every programmer should know
The only one big thing every programmer should know - Feb 18, 2011 at Developers Summit 2011
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Route 477
アジャイル開発とTDDを半年間実践してみた顛末と、これから
