.NET Tools ： テスト駆動開発ツール最前線（後編）（2/3） - ＠IT
これが意味するところは、従来はテスト対象のメソッドの表側しかチェックしていなかったものが、メソッドの裏側からもチェック可能になることを意味する。表側のチェックは、メソッドがすべての処理を終了してから結果をチェックすることになるので、メソッドのどこで問題が起きたか分かりにくい。 それに対して、裏側のチェックは、パラメータに渡したMockオブジェクトのメソッドが呼び出されるときに行われるので、テスト対象メソッド実行の途中で意図した呼び出しシーケンスから外れた瞬間にそれを検出することができる。それにより、問題発生個所の検出精度がアップするとともに、より具体的に問題の内容を把握できる可能性が出てくる。 では、具体的に、このようなMockオブジェクトをどのように用意すればよいのだろうか。もし、あまりに膨大な手間がかかるのであれば、いくらメリットがあろうと現場では実践できないことになる。果たして、どの
C# 2008 Express + NUnit 2.5 で、 初めてのテストファースト Step by Step - TDD.NET
C# 2008 Express + NUnit 2.5 で、 初めてのテストファースト Step by Step ※ 初出: biac の それさえもおそらくは幸せな日々@nifty 「NUnit の "Hello, world!" ～ C# 2008 Express + NUnit 2.5 で、 テストファーストの Step by Step」 ( 2009/05/27 ) NUnit をインストールして動作確認までできた ので、 次は、 NUnit を使ってテストファーストでプログラムを作る方法についてです。 開発環境としては、 Visual Studio 2008 Express Edition SP1 の C# を使います。 なお、 Visual Studio 2008 の Pro. 版以上には、 MS 独自の単体テスト機能がありますが、 基本的な考え方は NUnit を使う場合と変
moroの日記 - Railsでテストを書く勘所
昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基本的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは
RSpecの標準Matcher一覧表 - 本当は怖いHPC
追記2（2015/09/08）ありがたいことに、未だにこの記事をブックマークしてくださる方がいらっしゃいますが、2008年に書いた記事なのでご注意下さい。内容はアップデートしていません。私自身はすでにRubyを使っていません。 追記：古い情報ですので、記事の日付とお使いのRSpecのバージョンを見比べて、参考程度にご覧ください。大部分は通用するはずですが。 Matcherをいちいち調べるのが面倒になって、公式のリファレンスマニュアルは一覧性が低いから、自分で一覧表を作った。 RSpecそのものについては、スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)などをどうぞ。そのうちRSpec on Rails版も作る予定。 名前 not((should_notで使えるかどうかという意味。)) 意味・機能 == ○ ==演算子を利用して比較する。ex
ヽ( ・∀・)ノくまくまー(2009-07-21)
UnitTest で部品をしっかり守っているのに運用時にエラー さらに version up 時には頑張って書いた UnitTest が無駄になる UnitTest の存在意義に疑問が出てくるから、書こうとする気力が落ちる 思考停止して頑張ってまた書いても、また運用時にエラーが起きちゃう こうして悪いリズムが生まれていく 長期的な回帰テストとしては UnitTest は無力 まず書くべきは End to End のテストだった・・・ 河田・・・受入テストにつけ！ なるほど、UnitTest よりも受入テストの方が対象となるシステムの挙動と密接であるため、確かに テストコードが長生きする とことがわかる。うん、それで問題が解決しているよ。でも、さらに「実行者が人でないといけない」と言ってるのはなぜ？ここからが問題の核心だが、その答えから言えば 人である方がテストコードがさらに長生きする から
Shoulda（もっと早く使っていれば）by 達人プログラマ。Rubyのテストには、RSpecもいいけど、Shouldaが良いよ。 « kentaroi’s weblog
Shoulda（もっと早く使っていれば）by 達人プログラマ。Rubyのテストには、RSpecもいいけど、Shouldaが良いよ。 Rubyのテストには、RSpecもいいけど、Shouldaが良いよ。ってことで、 達人プログラマのDavid ThomasがShouldaを分かりやすく紹介してくれていたので、仮訳してみたよ。 （翻訳・公開することを快く承諾してくれました。） 英語が苦手なので間違いもあると思います。指摘してくれると嬉しいです。 オリジナルの記事：Shoulda used this earlier —– ここから —– Shoulda（もっと早く使っていれば） 色んな意味で、ソフトウェアをテストすることは、外に出て運動をすることに似ている。しなきゃいけないことは分かってるし、運動は自分を良い状態にしてくれるのは分かってるんだけど、それをやらない言い訳を考えるのもすごく簡単だ（
Ruby スクリプトのユニットテスト・チュートリアル - WebOS Goodies
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 少し前に公開した Ruby 用 JSON クラスに数多くのバグを仕込んでしまい（たいへんご迷惑をおかけしました m(_ _)m）、テストの重要性を改めて痛感している今日この頃です。今後も開発を続けるにあたって、現在の行き当たりばったりなテスト方法ではとてもやっていけないと危機感を持ちまして、きちんとしたユニットテストの方法を調べてみました。 で、実際に試してみたと
4)Railsテスティング環境 2009 - Cucumber,Webrat and Rspec - - 技術メモ的なモノと気になるモノ
諸橋恭介さんの発表(発表スライドはこちら) まとめ Cucumberが登場した事によってプログラマーのテスト環境が変わっている 受け入れ場Cucumber TDDはRSpec Choronicle of Rails Testing 1)Railsでのテストの歴史 〜2006はUnitTest(モデル),FunctionalTest(画面っぽい単位) 2007〜2008はRSpecがRailsと同時に使える。IntegrationTest(アクション／複数の画面をまたぐ）が入ってきた 2009になって、IntegrationTest部分にCucumberが登場 2)TestUnitとFunctional Testだけの時 UnitTest モデルのテスト データはFixtures FunctionalTest コントローラー／ビューのテスト IntegrationTest アクションをまたぐ
ウノウラボ Unoh Labs: テスト計画書のテンプレート
こんにちは！やまもと＠テスト番長です。 巷ではインフルエンザが流行っているようですが、皆さんお元気にお過ごしでしょうか。 さて、プロジェクトが立ち上がったとき、（特に受託案件の場合） テストのドキュメントはどうしようか？という話が出ると思います。 適当にやる訳にも行かないけれどIEEE829をベースにしたものだと重かったり、割と迷う部分です。 英語ですがテスト計画のテンプレートを配布しているサイトがあったので、ご紹介してみます。 Pragmatic Software http://www.pragmaticsw.com/ Software Development Templates http://www.PragmaticSW.com/Templates.asp テスト計画書 Test Design - http://www.pragmaticsw.com/Template_Te
WritingTestableCode - テストできるコードの書きかた
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
プログラマの思索: Testlink設定メモ
TestLinkを運用する時の設定メモ。 TestLinkはRedmine以上に癖が多く、デフォルト機能のままではすごく使い辛い。 大人数でテストケースを厳格に管理しようとして、逆に使い辛くなっているから、基本は制限を緩めた方が使いやすいと思う。 #八朔さんへの援護射撃になるかな？ 【環境】 TestLink 1.7.4 【1】RedmineとTestLinkの連係 TestLinkテストケースが失敗になったら、バグ登録する。 この時、BTSと連携する重要な機能。 Mantis、Bugzilla、Trac、Redmineが連携可能だ。 BTSのURLを設定するだけでOK。 この機能を使うと、テスト実行画面で「失敗」ケースのバグアイコンからバグ管理IDを登録すれば、BTSのチケットへリンクできる。 更に、テスト結果画面にある「失敗したテストケース一覧」リンクから、NGケースとRedmineの
Visual Studio 2008単体テスト機能のすべて ― ＠IT
Visual Studio 2008単体テスト機能のすべて：特集：Visual Studio 2008単体テスト機能徹底活用（前編）（1/4 ページ） 連載目次 Visual Studio 2005（以下、VS 2005）では上位エディションであるTeam Developerでのみ利用可能だった単体テスト機能が、Visual Studio 2008（以下、VS 2008）からは、Professional Editionでも利用可能になった。 VS 2008の1機能として導入されるほど単体テストが脚光を浴びるようになったのは、やはりアジャイル開発の普及だろう。アジャイルで開発する場合、単体の品質が非常に重要になる。また、リファクタリングなどで繰り返しテストが必要になるケースが多いため、テストを自動化するという考えが生まれ、単体テストの注目度はさらに増している。 本稿では、このVS 2008
第1回 テスト管理システムとは何か？ | gihyo.jp
はじめに TestLinkとは、オープンソースのテスト管理システムです。TestLinkは、Francisco Mancardi氏、Andreas Morsing氏、Martin Havlat氏を中心としたコミュニティで開発されています。元々は海外で作られていたソフトウェアでしたが、最近は日本でも徐々に浸透してきているようです。 本連載では、TestLinkの日本語化に携わっているTestLink日本語化部会の私たちが、このTestLinkの基本機能について順次ご紹介していきます。 今回はTestLinkのご紹介する前準備として、「テスト管理システムとは何か」「では、そもそもテスト管理とは？」といったことについて考えてみましょう。 テスト管理システムとは何か 「テスト管理システム」と言う言葉を聞いたことはありますか？ もしかしたら、「バージョン管理システムやバグ管理システムなら聞いた
functional test をめぐる冒険 - elm200 の日記(旧はてなダイアリー)
趣旨 自動テストは重要だ。この主張に真っ向から異を唱えるひとは多くないだろう。 だが実際には、テストを書くのはいささか面倒だ。特にコントローラのテスト(functional test) に苦手意識を持っている人は多いのではないか。post やら get やらいろんなメソッドが前触れもなく出てくるコントローラのテストは、モデルのテスト(unit test) に比べると「ワケわからん」感が強い。そこで今日は、functional test の仕組みについてしつこく探究してみる。仕組みを理解しないと、コントローラのテストは書きづらいと思うからだ。 functional test の例 簡単なブログエンジンを作るとしよう。 Entry(ブログ記事) というモデルを考えて、それを CRUD するコントローラとビューの足場（scaffold) を作る。 % rails -d sqlite3 blog_
ウノウラボ Unoh Labs: 見ないと損する ソフトウェアテスト関連サイト色々
こんにちは！やまもと＠テスト番長です。 今回は自分が普段チェックしている、ソフトウェアテスト系のサイトを色々ご紹介してみようと思います。既にご存知のサイトもあるかと思いますが、宜しくお付き合いください。 swtest.jp/wiki http://www.swtest.jp/wiki/index.php?swtest.jp/wiki 最近wiki化され、情報更新が活発になっています。必見です。 StickyMinds.com http://www.stickyminds.com/ コラムなどの読み物が充実しています。 Google Testing Blog http://googletesting.blogspot.com/ グーグルのテストチームのブログです。面白くないはずがありません。 Open source software testing tools http://www.
プログラマの思索: TestlinkがExcelのテスト仕様書よりも素晴らしい点
TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて
UIオートメーションによる自動UIテストの実践 ― ＠IT
特集：UIオートメーションによる自動UIテストの実践 WindowsアプリのUIテストを自動化しよう クロノス 亀野 弘嗣 2008/06/03 読者の方々は、UI（ユーザー・インターフェイス）にかかわるテスト（以下UIテスト）を自動化できているだろうか？ UIテストを自動化しようとしても、UIテストのコードは記述しにくく、記述方法に一貫性がない、などの理由から、自動化をあきらめる場合が多いのではないだろうか。 .NETの開発においても単体テストの自動化は一般的に行われるようになってきているものの、UIテストの自動化はそういった理由で実現が難しく、あまり行われていないのが現状だ。 そこで本稿では、標準的で一貫性のある記述ができるMicrosoft UIオートメーション（以下UIオートメーション。詳細後述）と、テスト・ツールであるNUnitを使用して、UIテストを自動化する方法を紹介する（N
gihyo.jpにて連載させていただいたテスト駆動開発のWeb連載もとうとう最終回を迎えました - t-wadaの日記
http://gihyo.jp/dev/serial/01/tdd/ 技術評論社様の情報サイト「gihyo.jp」にて、動画と連動した連載のかたちとして書かせていただいた今回のWeb連載も、ついに連載終了の日を迎えました。一応公約通り年内で連載終了まで来ましたね。お読みくださった方々には本当に感謝いたします。ありがとうございました。 ここで連載の全記事に、リンクを張っておきます 第1回 連載を始めるにあたって 2007年10月26日 第2回 「テスト駆動開発」とは何か？ 2007年10月30日 第3回 「テスト」という言葉について ── Developer Testing，Customer Testing，QA Testing 2007年11月2日 第4回 ナントカテスト ―― ユニットテスト，単体テスト，機能テスト，結合テスト，受け入れテスト 2007年11月6日 第5回 進捗管理として
Rubyのカバレッジツール·rcov MOONGIFT
システム開発におけるテストの重要性は言うに及ばない。が、大抵時間がなくなってしまって正常系のテストだけで終わってしまうことになる。 そうすると、もちろん異常系の処理になった途端、システムエラーを引き起こす。何をすべきか、それは予期している問題点を全て把握できるかどうかだ。 今回紹介するオープンソース・ソフトウェアはrcov、Ruby向けのソースカバレッジツールだ。 カバレッジツールとは、対象のプログラムソースが処理を一巡する中で通った場所と通っていない場所とを見極めてくれるソフトウェアだ。これを使えば通っていない場所は元々不要か、またはテストしていない場所かのどちらかに分けることができる。 結果はHTML形式でのレポートの他、標準出力でも可能だ。全体のコード量に対するカバレッジ率や、あるポイントを何回通ったかといったことも提示してくれる。 なお、公式サイトではRuby on Railsでも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あなたのテスト、単なる動作確認になっていませんか？
