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
はじめに 前回の記事『C#で始めるテスト駆動開発』では、TDD Boot Camp(TDDBC)横浜の課題を使って、NUnitを使ったTDDの手順を紹介しました。おかげさまで好評をいただけたようで、多くのかたに読んでいただけました。ありがとうございます。 Twitterで呟かれた読者の感想に、Visual Studio標準の単体テスト機能(MSTest)よりもNUnitの方が人気なんだろうか、というものがありました。人気のほどは分かりませんが、開発現場ではMSTestを使っているところもあります。そこで今回は、前の記事で書き漏らしたことをいくつか補足させていただいた後、MSTestを使ったTDDについて説明します。 対象読者 TDDに興味をお持ちの.NET Frameworkの開発者。 必要な環境 サンプルコードはC#で、Visual Studio 2010 Ultimateエディションを
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経由で教えていただければ差し上げます。 追記2 このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Announcing DevExpress Universal v23.2 Developer Express Inc is proud to announce the immediate availability of its newest release, DevExpress v23.2. Built and optimized for desktop, web, and mobile developers alike... DevExpress Wins 19 Visual Studio Reader's Choice Awards Like previous years, DevExpress dominated Visual Studio Magazine's 2023 Readers Choice Awards. We thank all our loyal users fo
Unit Testing Multi-Threaded Asynchronous Events July 10, 2007 — jopincar I recently developed a stress/load testing tool. One of the classes implemented the Event-based Asynchronous Pattern. A good unit test for this class would be that the event is raised when expected (or at all). I found some posts on how to test events using NUnit. However, I did not see anything directly addressing the multi-
何を今更、なことかもしれないないのだけど、もしかしたらこれを知ることでTDD(Test-driven development)をやることのハードルが一気に下がる人がいるかな、と思ってメモ。 特に、ある程度プログラマとして経験があるけど、どうもTDDは慣れないという人向き。 “TDDとは、TDD以前に脳内や機上でやっていたことをコードに落とすことに過ぎない” このことが解ってから、TDDをするのが一気に苦痛ではなくなり、むしろ楽しくなった。 TDDでなくても、コーディングをするとき、temporaryなテストコードを書いたり、目視でのチェックはしたりするものだろう。たとえば、一時的に変数の値をハードコードして挙動を変えてみて、それを目視で確認したり、printデバッグとかもその一部だ。 つまり、このtemporaryなコードや目視している部分をpermanentにするのがTDDで書くテストコ
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき(既存のソフトウェアの次バージョンから始める場合には言及がない) テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く