テストダブル - Martin Fowler's Bliki in Japanese - TestDouble
http://martinfowler.com/bliki/TestDouble.html Gerard Meszarosが、様々なXunitフレームワークを使用したパターンを集めた書籍を執筆中である。 彼は、ある厄介なことに出くわしている。 システムの一部分をテストするためにスタブ化することがあるが、 その名前というのが、スタブ、モック、フェイク、ダミーなど、色々とあるのだ。 そのため彼は、自身の用語集を作成した。 この用語集は広く普及すべきものだろう。 彼が一般的な用語として使っているのは、「Test Double（テスト代役）」という言葉だ（スタントの代役(double)を想像してほしい）。 Test Doubleは、テスト用にオブジェクトを入れ替えるときに一般的に用いられる言葉である。 Gerardが作成したリストには、様々なDoubleが載っている。 ダミーオブジェクトは、受け渡
テスト駆動開発入門ネクストステップ
テスト駆動開発入門ネクストステップ 1. テスト駆動開発入門 ネクストステップ 井芹洋輝 TDD Boot Camp 東京 for C++ 2011/10/8 @国立情報学研究所 2. 謝辞 • 主催の今給黎さん • 和田さん、会場提供、スタッフの方々 • 参加者の皆さま 深くお礼申しあげます 3. 自己紹介 • 井芹 洋輝(@goyoki/id:goyoki) • 組み込みエンジニア • WACATE実行委員/TDD研究会 • 講演/執筆： – XP祭り関西「ユニットテストの保守性を作りこむ」 – Androidテスト祭り「テストの活用による開発効率化」 – 並カン「FPGA/HDLを活用したソフトウェア並列処理の構築」等 4. 概要 本講義はTDDの基本サイクルを学んだ方 が対象です。 本講義ではTDDを開発で実践するための 知識、TDDについて自立して学習を進め るための情報を学び、
ユニットテストの網羅性の扱いについて - 千里霧中
テストの網羅性については様々なものがある。基本的な網羅性の観点としては、構造ベース、仕様ベース、外部の標準や指標ベースなどが挙げられる。 そして観点ごとに、様々な網羅性の指標がある。ユニットテストの場合だと、例えば以下がある。 コードの構造網羅 コードの構造を網羅する。ここでいうコードの構造としては、制御フロー、データーフロー、例外フローなどがある。具体的な指標としては、コードカバレッジが有名。コードの構造網羅では、コードカバレッジなどを基準にして、基準以上の網羅性を確保できるようにテストを設計する。 なお、構造網羅というと、一般的な定義ではコード以外の構造も扱われるが、このブログでは便宜上「構造網羅をコードの構造を網羅すること」という定義に絞り込んで説明する。 仕様網羅 コードの仕様を網羅する。コードの仕様には、対象（対象の粒度はテストレベルに依存する。例えば関数やクラス、モジュールを単
テスト駆動開発・パターン編 - Strategic Choice
ケント・ベック師の著書で、TDDの教科書「テスト駆動開発入門」の「Part3 テスト駆動開発のためのパターン」をまとめ、「TDDの戦略」「TDDの定石」「TDDのプラクティス」を身につけます。はじめにファーストステップテスト駆動開発のパターンテスト方法の詳細の前の、基本的な戦略に関するパターンです。「テストすることは何を意味するのか」「いつテストするのか」「テストするロジックをどのように選択するのか」「テストするデータをどのように選択するのか」を吟味します。Test（テスト）Isolated Test（独立したテスト）Test List（テストリスト）Test First（テストファースト）Assert First（アサートファースト）Test Data（テストデータ）Evident Data（明示的データ）レッドバーに関するパターンテスト作成を開始するタイミング、テストを作成する場所、テ
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
Selenium
Selenium automates browsers. That's it!What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should) also be automated as well. Selenium WebDriver If you want to create robust, browser-based regression automation suites and tests, scale and di
深夜のテストTL
ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13
メトリクスでソフトウェア品質を見える化する - プログラマの思索
「現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。 【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。 内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。 【本書で解説するEclipseプラグイン】 ・Checkstyle → コーディング規約チェック ・FindBugs → バグパターン検出 ・JUnit → 単体テストの作成/実行 ・TPTP → プロファイリング(非機能テスト) ・djUnit → カバレッジ計測 ・StepCounter → ソースコード行数測定 上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか？ 僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは
電気通信大学：西 康晴 先生インタビュー：第2回：日本のテストの現場への提言 | 豆蔵ソフト工学ラボ
電気通信大学：西 康晴 先生インタビュー 第2回：日本のテストの現場への提言 印刷 株式会社豆蔵 取締役 プロフェッショナルフェロー 豆蔵ソフト工学ラボ所長 羽生田 栄一 2009/12/03 ［テスト・品質改善］ 日本のテスト業界の立役者である電気通信大学の西康晴先生へのインタビュー、第2回は日本のソフトウェア開発におけるテストや品質確保の取り組みに対しての所感と提言です。 大学での研究の在り方から、産業構造の問題点まで、率直なご意見の裏側に日本のテスト技術の向上に対する熱い思いを感じる内容です。 日本は欧米に比べてソフトウェアテストや品質が専門の研究者が少ないような気がしますが、この傾向は今後変わるでしょうか。 西: まず、どこの国でも開発系の研究者が圧倒的に多いということが前提ですが、特に日本でテストの研究者が少ない背景には技術の系譜の問題があると思います。 ソフトウェアという領域
InfoQ: Bobおじさんが述べるTDDの適用可能性
原文(投稿日：2009/11/04)へのリンク "TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。 氏はまず"TDDはアーキテクテャの代替物か？"という大きな問題を取り上げ、実例を背景に「そうではないですが、しかし...」と答えている。 いちから始めて次々にテストケースを書いていくことで実行可能なアーキテクチャを生成できるという意見は全くばかげたことです。テストしないという決断を下す必要もあります。 もちろんこれらの決断の多くはできるだけ先延ばしにすることができるし、そうすべきです。例えば、データベーススキーマは恐らく長い時間待つことが可能なものです。Spring、JSF、Hibernate、JPAなどを使うかどうかの決
コントローラのテストでフィルタをスキップ - moroの日記
Yugui さんの「RSpecにおけるコンテキストをまたぐ共通部分」が面白いので私も Tips を。 コントローラにフィルタ*1をもりもり書いていくと、テストする場合に事前準備がすごくめんどくさくなる(ユーザ Foo でログインしてなきゃイケナイ、とかなんとか)んですが、その場合の Tips です。 spec_helperとか、そこから読み込む先に以下のように定義しておくと結構便利です。 module Spec:Runner class ExecutionContext module InstanceMethods def skip_filter(*filters) filters.each do |filter| controller.should_receive(filter).and_return(true) end end end end end 使う場合は context "th
OSC2009 Tokyo/FallでCukeとRSpecの紹介をしました - moroの日記
休んでいるうちにずいぶん時間が経ってしまいましたが、10/31のOSCにてお時間をいただき、Railsの昨今のテスト事情について紹介させていただきました。普段から申しているようにCucumberとRSpecをぐいっと推しています。 Rails testing environment, 2009 fallView more documents from Kyosuke MOROHASHI.あとはRSpec方面で、subjectやitsの使い方について、使いながら考えているようなことを書いています。 前にオブラブ方面でCuctomMatcherの話をしたときに、簡単なCustomMatcherを量産するのはだるいんじゃない?という懸念があったんですが、その一つの解としてits()はありかなー、と。使い分けはこんな風になると思います。 CustomMatcher作る 検証内容が複雑になるとき エ
ViewのRSpecを書いてみた - yuumi3のお仕事日記
現在ネットショップを作っているのですが、やや複雑なビジネスロジックを持っています。当然モデルはRSpecを書いて仕様の確認(テスト)しているのですが、開発中に注文の確認画面の表示がおかしい問題がよく発生しました。 View自身はモデルやヘルパーの呼び出しが主ですが if で表示を変えたりする部分もありモデルが正しいからといって表示も大丈夫とはなりません。 さらに、注文の確認画面はお客様に、お買い物の金額を伝える大切な画面です。ここにバグがあるとネットショップとしてはたいへんな問題になります。ということで 注文の確認画面 View にもテスト・RSpecを書く事にしました。 ViewのRSpecの書き方 RSpecのページに View Example がありますが、これだけでは良く解りません ^^; しかし、RDocの中のサンプルがとても参考になります。 モデルやコントロラーのRSpecでは
Javaオブジェクトに対する操作の記録と再生 - @katzchang.contexts
元ネタ What Kind of Differences? Consider the following class. It defines an object that is able to record all the messages ever sent to it, and then playback those messages to another object. 以下のクラスは、オブジェクトに送られた全てのメッセージを記録し、他のオブジェクトで再生することが出来るよう、定義されている。 class VCR def initialize @messages = [] end def method_missing(method, *args, &block) @messages << [method, args, block] end def play_back_to(obj)
Testing Context(仮)という考え方 - Fly me to the Luna
ちょっと前Quick JUnitの管理者でもあるかくたにさんとQuick JUnitをどう改良しようか、話してきました。その時に聞いてきたアイディアに名づけるとするならTesting Context。 以前はTesting Pairだけ考えてればよかったのに。 Quick JUnitでは実装クラスに対するテストクラスが1対となって存在するという、Testing Pairという考えを元に作られています。Ctrl+9でテストクラスと実装クラスを切り替えられる、というあれです。JUnit3の時代までは必ずTestCaseクラスを継承しなければならない、テストメソッド名はtest_で始まらなければならないなど、いくつか制限がありました。なので名前で実装クラスとテストクラスを対応づけられるよう、実装クラス名+Testをテストクラス名として検索できるようになっています。実は隠してるんですが、その対応を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD について
InfoQ: よいアジャイルなメトリクスとは何か?
Seasar Conference 2009 White にて 「テスト駆動開発のこころ」というタイトルで登壇させていただきました - t-wada の日記（旧）