「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ 記事の内容が間違ってるとまでは言いませんが、これだけではミスリードしてしまう可能性が高いと思いましたので、簡単にですがアンサーエントリ書いておきます。タイトルでは「反論」と書きましたがどちらかというと「補足」に近いかもです。 前提の整理 「メソッド」という言葉が使われているため、オブジェクト指向的なパラダイムを持つ言語に限定した話であるという認識で書きます。その前提自体が間違っていたらご指摘ください。 元エントリの主張である「テストが説明的であるべきだ」ということを否定するわけではありません。ただ、それと「メソッドに対してテストをするな」という意図が異なるのではないかと主張したいだけです。 元エントリは Perl でサンプルコードで書かれているようですが、僕が Perl にそれほど明るくないため、このエン

最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が

http://t-wada.hatenablog.jp/entry/debugging-tests 和田さーん！ テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。 チーム内にテストを書く習慣を持ち込んで三年、最初のうちは工数が増えるだけだ（あるある）、テストを書いても不具合がでるじゃないか（あるある）、システムテストでカバーすればいい（あるある）などという抵抗があり、それでも僕は淡々と雨の日も、晴れの日も、雪の日も、朝も夜も深夜も、終電後のオフィスでも、GW中の人気のないオフィスでも、自動テスト

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ キーマンズネットは、IT担当者を対象にしたアンケート結果として「テスト自動化ツールの導入状況」を公開しました。 それによると、導入済みは全体の8.5％（「既に導入済みである（追加リプレイスなし）」7.5％と「既に導入済みである（追加リプレイスあり）」の1.0％の合計）で、導入を検討しているが4.8％。今後も導入しないするグループは86.7％（「必要性を感じているが導入を検討していない」の38.6％と、「必要性を感じない」の48.1％の合計）」になりました。 グラフを見ると従業員規模1001名以上では導入済みが約15％である一方、100名以下では1.8％であり、従業員規模によって大きな違いがあることが分かります。 対象言語はJavaがトップ、目的は品質の向上、工数削減など すでにテスト

garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も

ソフトウェアの組み合わせテストのテストケースをExcel上で自動生成する PictMaster という名前のExcelベースのフリーソフトです。 テストケース生成のエンジン部分はペアワイズ法(オールペア法)を採用したMicrosoftのフリーソフトPICTと大阪大学の土屋達弘教授が開発したCIT-BACHを利用します。 PICTとCIT-BACHはコマンドプロンプト上で動作するソフトですが、PictMasterはExcel上からGUIを使って簡単にPICTとCIT-BACHを使えるようにしたものです。 また約300種類の直交表テンプレートを内蔵し、直交表ツールとしてのテストケース生成もサポートしています。テスト対象に合わせて生成方式と生成エンジンを選択することができます。 さらにPictMaster独自の機能を追加し、使い勝手の向上も実現しています。 ※ 直交表方式の生成で "Triple

WACATE 2011 夏に誘われたのがキッカケでソフトウェアテストを勉強しはじめて10ヵ月くらいがたちました。 先日、わんくま名古屋でソフトウェアテストの勉強法についてLTしたのですが、みなさんにいろいろ聞かれたのでここにまとめておこうと思います。 本当は1年の区切りで書こうと思ったけど、まぁいいでしょう。 追記ここから わんくまで発表したLT資料はこちらです うさみみのソフトウェアテスト勉強法 View more presentations from Kyon Mm 追記ここまで こういうのを書くときに時系列で書くべきか、コツを書くべきか悩みますね。 でも、みんなが知りたいのは僕の歴史じゃなくってコツだと思うので後者で書きます。前者はTwitterとか勉強会とかお食事とかお茶でもしているときに聞いてみてください。 以下では多くの書籍を紹介していますが、僕がこの10ヵ月で読んだ本。ってい

マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム JaSST'12 Tokyo」が1月25日、26日の2日間、都内で開催されました。 10周年を迎えた今回のイベントの基調講演を行ったのが、開発しているソフトウェアの規模、分野、種類において世界最大の企業、マイクロソフトのプリンシパル テストリードのBj Rollison氏。 「How We Test At Microsoft（マイクロソフトでどのようにテストをしているのか？）」という題で、同社がどのようなソフトウェアテストを行っているのかを中心に講演を行いました。講演の内容をダイジェストで紹介しましょう。 開発者とテスターはほぼ同数 マイクロソフト プリンシパル テストリードのB

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

「現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。 【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。 内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。 【本書で解説するEclipseプラグイン】 ・Checkstyle → コーディング規約チェック ・FindBugs → バグパターン検出 ・JUnit → 単体テストの作成/実行 ・TPTP → プロファイリング(非機能テスト) ・djUnit → カバレッジ計測 ・StepCounter → ソースコード行数測定 上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか？ 僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは

はじめに－この特集のねらい この特集では、ソフトウェアの組み合わせテストについての技法である「オールペア法」と、オールペア法を採用したテストケース作成ツール「PICT」の機能、およびその効果的な使い方を、多くの例を用いて解説していきます。筆者はPICTを実際のテスト業務に1年半以上使用してきました。そこから得られたノウハウも合わせて公開したいと思います。 ソフトウェアはさまざまな因子（パラメータ）の組み合わせにより、その挙動が違ってきます。これらパラメータの組み合わせを総当りで行うことはテスト件数の爆発を招き、実際に行うのは多くの場合、不可能です。どのようにすればテスト件数の爆発を招かずに、しかもテストの質を落とさない組み合わせをテストできるかが重要な課題となっています。 こうした課題を解決するために考え出された効率的な組み合わせテスト技法は、大規模、複雑化するソフトウェアの組み合わせテス

第3回コピー＆ペーストでテスト仕様書を作っていませんか？ 鈴木三紀夫，池田暁 2008-07-14

第3回次期バージョン1.8に見るTestLinkの過去・現在・未来 TestLink日本語化部会 2008-10-17

「ツールがなかったらテストの実施は到底不可能だった」──。6月24日に東京・六本木ヒルズで開催された「Enterprise Test Forum 2011」で、ソニー損害保険 システム企画部 企画管理課長の佐伯陽一氏が基調講演に登壇（写真1）。「人海戦術のテストはもう時代遅れ～自動化で工数を10分の1に～」と題して、同社のシステム構築におけるテスト工程の自動化についてこう強調した（写真2）。 佐伯氏は、2010年1月に実施したWebシステム刷新、2011年1月に実施したコールセンターシステム刷新という二つのプロジェクトについて、それぞれのテスト工程をどう乗り切ったのか、同社の取り組みを紹介した。 二つのプロジェクトはいずれも、ハードウエアの老朽化に伴いサーバーを置き換えたもので、アプリケーションの再構築などは必要ない。だが、「単に機器を置き換えるだけのプロジェクトでも、新しいハードウエア上

ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ