なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
Test Driven Development – #Coder
Having recently watched Kent Beck’s Test-Driven Development Design (TDD) screen casts available for purchase from the pragmatic programmer website, I must confess I’ve been converted. I have been writing unit tests for a few years now, and prior to NUnit supporting .NET 2.0 I wrote my own unit test framework, a simple Test Runner which used attributes and reflection to identify and execute tests,
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 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でもたぶん作れると思います。
TDD Boot Camp 福岡 0 日目 - ぐるぐる～
前日譚てきな。 みずぴーさん (id:mzp) と一緒に、新幹線で博多に。 新幹線の中ではプチハッカソン状態で楽しかったです。 博多について、新幹線のホームを降りてエスカレータ降りたらなんか前来た時と全然違ってビビった。すごくきれい！ で、なかやんさん (id:pocketberserker)、hiro さん (@cz75hiro) と合流して、空港で和田さん (id:t-wada) と合流。 ラーメン食べてソフトクリーム食べてもつ鍋食べました。 会場まで hiro さんに送ってもらい、そこで別れて残りの 4 人で準備開始！ 今回お題の元ネタを考えたのですが、和田さんに助けてもらいつつ変えていったら、すっかり別物になりました。 お題の作り方は非常に参考になりました！ ちなみに MotsunabeZombieProject (略称 mzp) ですが、こんな感じで決まりました。 俺「なんか格好
ユニットテストの網羅性の扱いについて - 千里霧中
テストの網羅性については様々なものがある。基本的な網羅性の観点としては、構造ベース、仕様ベース、外部の標準や指標ベースなどが挙げられる。 そして観点ごとに、様々な網羅性の指標がある。ユニットテストの場合だと、例えば以下がある。 コードの構造網羅 コードの構造を網羅する。ここでいうコードの構造としては、制御フロー、データーフロー、例外フローなどがある。具体的な指標としては、コードカバレッジが有名。コードの構造網羅では、コードカバレッジなどを基準にして、基準以上の網羅性を確保できるようにテストを設計する。 なお、構造網羅というと、一般的な定義ではコード以外の構造も扱われるが、このブログでは便宜上「構造網羅をコードの構造を網羅すること」という定義に絞り込んで説明する。 仕様網羅 コードの仕様を網羅する。コードの仕様には、対象（対象の粒度はテストレベルに依存する。例えば関数やクラス、モジュールを単
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
TDD Boot Camp 札幌に登壇させていただきました - t-wada の日記（旧）
TDD Boot Camp もとうとう北海道に上陸です。1/22, 1/23 の2日間開催された「TDD Boot Camp 札幌」に登壇させていただきました。参加くださった皆様、そして企画を立ち上げ主催した id:shuji_w6e さん、ありがとうございました。 TDDBC 札幌も素晴らしいスタッフワークにより、素敵なイベントになったと考えています。 イベントの構成は TDDBC 2日間二部構成のコースで、結果的には次のような構成で行いました。 一日目午前その1 導入講演。『プログラマが知るべき97のこと』からテストに関するエッセイを中心に紹介。 一日目午前その2 TDD についての講演 一日目午後その1 TDD & ペアプロについてのデモ (with id:shuji_w6e さん) 一日目午後その2 (ペアプロ+コードレビュー)×2 一日目夜 懇親会 二日目午前その1 応用トピック
レガシーコードをライブで扱う際のポイント試案
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
テスト駆動開発とかんばんは似ている、とケント・ベック氏
コードを書くときにまずテストから書き始め、そのテストが通るようにコードを書くことで開発を進めていく「テスト駆動開発」。テストファーストとも呼ばれますが、この開発手法と、「かんばん」と呼ばれる、現場の進捗状況をかんばんによって見える化することで、開発プロセス全体の無駄をとり、価値の流れを作り出す手法には共通点が多い、というエントリ「TDD is Kanban for Code」をブログにポストしたのは、エクストリーム・プログラミング (XP) の考案者でアジャイルソフトウェア開発宣言の起草者の一人でもあるケント・ベック氏。 この2つにどのような共通点があるのでしょうか？ かんばんとテスト駆動開発 「かんばんの目的は、開発プロセスの中で価値の流れを最大化することだ」とケント・ベック氏。簡単にまとめると、かんばんでは看板を使って各工程を見える化することで、下流工程から上流工程に要求が伝わり、仕掛
JUnitの歴史とテスティングの未来 - 野生のペタシ (Le pédant sauvage)
Software Engineering RadioというPodcastの、ケント・ベックのインタビュー（以下URL）が面白かったので要点を日本語訳したい、という話がもちあがった。 http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/ 平鍋さんがご自身のブログで言い出した話である。 http://blogs.itmedia.co.jp/hiranabe/2010/10/the-history-of.html 平鍋さんの後を@urimaro(id:goh-m)さんが引き受けて、さてその後が続かないようで、「誰か続きをやりませんか？」と平鍋さんがツイッターでつぶやいたのを見て、ちょっと面白そうかも、と思ったわたくしが酔った勢いで「やりま
#tddbc イベント設計についての議論(9/24)
TDD Boot Camp (#tddbc : これまで東京、北陸、名古屋で開催) で、今後どういうことをやりたいか、やったら面白いかというテーマでの議論です。 誰でも編集可能にしてあるので、追加したい意見がある場合、自分のつぶやきを消したい場合などは、お気軽に編集してください。
Writing Great Unit Tests: Best and Worst Practices
This blog post is aimed at developers with at least a small amount of unit testing experience. If you’ve never written a unit test, please read an introduction and have a go at it first. Published Aug 24, 2009 What’s the difference between a good unit test and a bad one? How do you learn how to write good unit tests? It’s far from obvious. Even if you’re a brilliant coder with decades of experienc
深夜のテストTL
ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13
TDDはテスト手法か否か
なんもわからん @babie TDDは論理実証主義的な面が強調されすぎたために、BDDなどという言い換えが行われた。反証主義的に、エラーを積極的に起こそうとするテストを書くべき。 2010-02-21 13:45:09
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck)): Steve Freeman, Nat Pryce: 本
gihyojp - ニコニコ
TDD について
