proveをうまく使ってテスト実行を効率化しよう - Articles Advent Calendar 2010 Casual
こん(にちは|ばんは)．最近は卒論でC/アセンブラ，アルバイトでPerl/Objective-Cと高低レイヤーを行ったり来たりなyaottiです． このエントリでは，テストを実行する時に便利なproveコマンド(App::Prove)の便利な機能+αについて紹介します． 基本的な使い方 prove t/foo.t のようにして使います．perlと同じように-lや-Idir，-v, -MModule::Nameなども使えます． prove -l -Ilib -v t/foo.t 他にも，-Pオプションでプラグインを利用することもできます． 例えばmotemenさんの書いたApp::Prove::Plugin::ProgressBar::Eachは大量のテストを実行するときに便利です． cpanm https://github.com/motemen/App-Prove-Plugin-Prog
自動テストの知識をプログラマは知らないと恥ずかしい | Act as Professional - hiroki.jp by HIROCASTER
１．テストやデバッグに使う時間を削減して、プロダクトコードの品質をあげる 単体・結合・統合テストは全体の8〜25%が費やされるべきであるといわれています。ですが、デバッグは開発の50%におよぶ場合があると言われています。これは、テストには本来多くの時間を割くべきであるが、デバッグが膨大な時間に及ぶことが事実としてあるということです。 プログラミングについてあまり知られていない７つのことより １．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッ
バグのないプログラムを作るための技術 - eomole blog 4 くらい
2015/12/10 追記: バグを本気で無くしたい方はこんな良く辺鄙なブログなんて見ずにソフトウェアエンジニアリング系の国際学会に行くなり、そこの論文を読むなりするといいと思います。ICSEなんかは日本語の勉強会資料もあってとっつきやすいでしょう。 バグのないプログラムを作る方法について色々聞きかじったことを, 脈絡なく訳の分からない説明でつらつらと書きならべます. テスト 割と古典的な方法ですね. プログラミングコンテストでもお馴染みの方式です. Java だと JUnit (4) みたいなのを使います. 手作りケース とりあえず試してみるケース コーナーケース ミスの発生しやすそうなところを突くためのケース ランダムケース ランダムに爆撃するためのケース みたいなものを作って, 仕様とマッチするか確認します. 当たり前ですが, 基本的には下手な鉄砲も数撃ちゃ当たる方式なので, 運が悪
Google Test ユーザーが Boost.Test を使ってみた
この記事は、C++ Advent Calendar 2012: 17日目の記事になります。 お題は「Google Test ユーザーが Boost.Test を使ってみた」です。 (2012/12/27: 補足記事を書きました。) これまで、C++ の testing framework には Google Test を使ってきたのですが、 この機会に Boost.Test に挑戦したいと思います。 今年２月に行われた「Boost.勉強会 #8 大阪」の参加報告で Boost.Test 使うぜ！っと意気込んでおいて今更かという感じではありますが・・・ では、なぜ今まで使わなかったのかというと boost の導入がめんどくさそう 日本語情報が少ない Google Test が使いやすかった と、いう勝手なイメージがあったからです。最後のが一番大きな理由でした。 でも、他のフレームワークのこと
テストについて考える #devlove
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
テスト自動化に関するスライドの紹介
みなさんこんにちは。@ryuzeeです。 SlideShareでテスト自動化に関する良いスライドをみつけたのでご紹介します。 Agile Toolkit http://www.slideshare.net/nverdo/agile-toolkit-mo-conf 参考になる部分は以下の3スライドでしょう。順に説明していきます。 手動テストのコストプロジェクトの初期は以下のような状況です。 テストする項目は少ない手動でテストを完了するのも簡単まだプロダクションでもないし、問題があって影響を受けるのは限定された人だけしかし時間がたつにつれて 手動でのテストにはとても多くの時間がかかるようになる製品が出荷されてしまうと、バグによってとても多くの人が影響を受けることになってしまうという状況に変わっていきます。 右のグラフは手動でテストを行った場合のテスト時間の推移を示していますが、見て分かる通り、
Omega test and beyond
5. 最近の興味: 色々な決定手続きのオモチャ実装 • Presburger Arithmetics • Gomory’s Cut • Omega Test • Conti-Traverso • Cooper’s Algorithm • SAT / MaxSAT / Pseudo Boolean (DPLL, CDCL) • Real Arithmetics • Uninterpreted function • Fourier-Motzkin variable (Congruence Closure) elimination • 実装したいと思ってるもの • Simplex method • Gröbner basis (Buchberger) • CAD (Cylindrical Algebraic Decomposition) • (Mixed) Integer Programming
第16回 Haskellでのテストの自動化を考える
皆さんはプログラムが正しく動作することをどうやって調べていますか？ いちいち実行して確認している人もいるかもしれませんが，多くの人はツールや自作のプログラムを使って何らかの形でテストを自動化しているでしょう。ここ10年くらいで「テストの自動化」はプログラマにとってなじみの深い概念になりました。今回はHaskellでのテストの自動化を取り上げます。 型検査を利用する 実は，Haskellを使っていれば，すでにテストはある程度自動化されていると言えます。 第12回と第13回で説明したSTMでは，STMモナドという特別なモナドを使い内側にI/Oアクションを記述できなくすることによって，取り消し不可能なアクションが入り込むことを防いでいました。 Prelude Control.Concurrent.STM> atomically (writeFile "sample.txt" 12) <inter
Test Anything Protocol - Wikipedia
This article is about An automated testing protocol. For the network tunnel driver, see TUN/TAP. This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Test Anything Protocol" – news · newspapers · books · scholar · JSTOR (October 2017) (Learn how and when t
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
NSubstitute: A friendly substitute for .NET mocking libraries
//Create: var calculator = Substitute.For<ICalculator>(); //Set a return value: calculator.Add(1, 2).Returns(3); Assert.AreEqual(3, calculator.Add(1, 2)); //Check received calls: calculator.Received().Add(1, Arg.Any<int>()); calculator.DidNotReceive().Add(2, 2); //Raise events calculator.PoweringUp += Raise.Event(); ReceivedCallsException : Expected to receive a call matching: Add(1, 2) Actually r
テストファーストの弊害
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ キーマンズネットは、IT担当者を対象にしたアンケート結果として「テスト自動化ツールの導入状況」を公開しました。 それによると、導入済みは全体の8.5％（「既に導入済みである（追加リプレイスなし）」7.5％と「既に導入済みである（追加リプレイスあり）」の1.0％の合計）で、導入を検討しているが4.8％。今後も導入しないするグループは86.7％（「必要性を感じているが導入を検討していない」の38.6％と、「必要性を感じない」の48.1％の合計）」になりました。 グラフを見ると従業員規模1001名以上では導入済みが約15％である一方、100名以下では1.8％であり、従業員規模によって大きな違いがあることが分かります。 対象言語はJavaがトップ、目的は品質の向上、工数削減など すでにテスト
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
単体テスト/結合テストなんて存在しない
テストプロセスを再定義する時代が来た。 単体テスト、結合テスト、システムテストといったテストレベルがテスト設計において寄与しているメリットはあるのか？ また、それらが結局はプロジェクトのマイルストーンをひくための単なる慣習的な単語であり、実作業に悪影響を与えているのではないか。 という疑問をもったうさみみことkyon_mmの話にソフトウェアテストクラスタの方がつきあってくださいました。 kyon_mmは現在、ソフトウェアテストを勉強しはじめたばかりの人です。 続きを読む
ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組
WACATE 2011 夏に誘われたのがキッカケでソフトウェアテストを勉強しはじめて10ヵ月くらいがたちました。 先日、わんくま名古屋でソフトウェアテストの勉強法についてLTしたのですが、みなさんにいろいろ聞かれたのでここにまとめておこうと思います。 本当は1年の区切りで書こうと思ったけど、まぁいいでしょう。 追記ここから わんくまで発表したLT資料はこちらです うさみみのソフトウェアテスト勉強法 View more presentations from Kyon Mm 追記ここまで こういうのを書くときに時系列で書くべきか、コツを書くべきか悩みますね。 でも、みんなが知りたいのは僕の歴史じゃなくってコツだと思うので後者で書きます。前者はTwitterとか勉強会とかお食事とかお茶でもしているときに聞いてみてください。 以下では多くの書籍を紹介していますが、僕がこの10ヵ月で読んだ本。ってい
)
単体テストのヒント: 時間と手間を節約するための保守可能な単体テストの作成 -- MSDN Magazine, 2006 年 1 月
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 時間と手間を節約するための保守可能な単体テストの作成 Roy Osherove この記事で取り上げる話題: 単体テストの真理 対象を正しく定めたテスト 保守可能なテストの作成 読みやすいテストの作成 この記事で使用する技術: Visual Studio 2005、Visual Basic 翻訳元: Write Maintainable Unit Tests That Will Save You Time And Tears (英語) 目次 単体テストの真実 対象を正しく定めたテスト 保守可能なテストの作成 読みやすいテストの作成 セットアップ メソッドでは部分的に関連するコードを使用しない 語の区分け 昨今は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iutest プロジェクト日本語トップページ - OSDN
http://www.jmock.org/oopsla2004_ja.pdf
googletest - Google C++ Testing Framework - Google Project Hosting
