レガシープロジェクトでテストの自動化を始めるRustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
テストを書くときはコストベネフィットを考えろ - ひがやすを blog
InfoQにKent Beckの最新の提案がでてますね。Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案 でも、これは、Kent Beckが「ごく短期のプロジェクトではテストを省略しても良い」といってるわけではないと思うんですよ。キャッチーなタイトルをたまたまつけられてしまっただけで。 重要なポイントはここだと思います。 Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。 つまり、「テストがかけた時間の割りに役に立つと思ったら書くし、そうでなければ書かない」ということだと思います。別に短期のプロジェクトでも、コス
【ハウツー】シンプル&タイプセーフなJava用モックライブラリ"Mockito"の魅力 (1) Mockitoとは? | エンタープライズ | マイコミジャーナル
ユニットテストを記述する際に問題になるのがモックの作成方法だ。テストケース時にモックに差し替えることを想定してしたコードであればテストケースでモックに差し替えることは難しくない。しかし、差し替えるモックを作成する手間は馬鹿にならない。そこで登場するのがモックライブラリだ。 モックライブラリはテストケースで使用するためのモックオブジェクトを手軽に作成するためのものだ。実際にモックオブジェクトのクラスを定義しなくても、動的にモックオブジェクトを作成できるものが多い。 Java向けのモックライブラリにはJMock、EasyMockなどさまざまなものがあるが、本稿で紹介するのはMockitoという比較的新しいモックライブラリだ。 MockitoのWebサイト MockitoはMITライセンスで開発されているオープンソースソフトウェアで、他のモックライブラリと比較して直感的な記述でモックの挙動を設定
JUnit and EasyMock - DZone Refcardz
Unit testing and test driven development are proven ways to improve both the productivity of a developer and the quality of their software. JUnit and EasyMock are the predominant choices for testing tools in the Java space. This reference card will guide you through the creation of unit tests with JUnit and EasyMock. It contains detailed definitions for unit testing and mock objects as well as a d
TDD、TDDと言うけれども。TDDのダークサイドについてそろそろ一言語ってみる。 - Fly me to the Luna
id:t-wadaさんの話の中で、TDDが品質を保証するわけではない、という話があったんですが、それについて私見をつらつらと。ちなみに自分は2年くらい仕事でTDDをやってきました。 やってきた中で下記のTDDの利点を感じることができました。 その時に気づいた最もシンプルなコード、クリーンなコードができる テストコードからコードを書く、と言うのはプロダクトコードの利用方法が考えられるのでとても有効に作用します。id:t-wadaさんもリファクタリングが一番重要と話されていましたが、テストコードがあれば安心してリファクタリングができます。 より高い品質のコードが書けるようになる これはt-wadaさんの話の中でもありましたね。なぜかと言うと、プロダクトコードが実行される時の前提条件を知ろうとすると、結構いろいろなコードに目を通すことになります。コードに目を通すことで優れた先人の知恵を見つけるこ
ウノウラボ 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.
Selenium RCによるFlash用の機能テストの作成と実行
Paulo Caroli ThoughtWorks* Henrik Lindahl Google* 目次 はじめに ソリューション概要 FlashSeleniumコンポーネント Selenium RCクライアント 印刷用に表示 作成日:2008年６月23日 更新日:2008年７月１日 ユーザレベル:中級 製品:Flash Flex 機能テストでは、システムが全体として期待どおりに機能することを検証します。すべてが正しく接続されていることも確認します。Selenium*は、Webアプリケーション用のオープンソーステストツールです。Seleniumは、Webブラウザ自体内で直接実行し、実際のユーザの操作をシミュレートします。Seleniumは、様々なブラウザとプラットフォームをサポートしています。特に、Webアプリケーションの機能やユーザアクセプタンスの検証テストを実行するときに役立ちます。
【ハウツー】Javaのビヘイビア駆動開発をやさしく現する"easyb"を試す (1) ビヘイビア駆動開発、そしてeasybとは? | エンタープライズ | マイコミジャーナル
本稿では、Java向けのビヘイビア駆動開発(Behavior Driven Development: BDD)フレームワークであるeasybを簡単に紹介する。 「ビヘイビア駆動開発」という用語になじみのない方のために簡単に説明すると、「ソフトウェアを書く前に、その仕様をコードで書く」という開発手法である。対して、皆さんおなじみの「テスト駆動開発(TDD)」は、「ソフトウェアを書く前に、そのテストをコードで書く」という開発手法だ。 この2つの開発手法は、「プログラムを書く前に、そのプログラムが正しく動くことを保証するためのコードを書く」という点ではまったく一緒だ。保証するためのコードもかなり似通ったものになる。ただし、TDDのコンセプトは「テスト対象のものがないのにテストを書く」というもので、あまり直観的とは言えない。対してBDDは、「仕様通りに動くことを保証するために、検証コードを先に書く
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論 目次 この文書について 単体テストに潜む誤った理論 単体テストに潜む誤った理論 この文書について "The Flawed Theory Behind Unit Testing" の日本語訳です http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 私は Google の blogsearch 一式を使って単体テストに関する話題を拾っている。 普段は一週間に数十の blog やメーリングリストの議論に目を通す。 新しい話題もたまにはある。けれど、多くの話題は繰り返しだ。同じ主張が何度も現れる。 その中でもひときわ私を悩ませる
jQueryのテスティングフレームワークQUnit (でぃべろっぱーず・さいど)
jQueryのSubversionリポジトリにtestフォルダがあって、jQuery自身のテストが納められていたのですが、そこで使われているテスティングフレームワークがQUnitとしてトップレベルのプロジェクトになったようです。 QUnit - jQuery JavaScript Library これを使うと簡単にjQueryプラグインのテストコードが書けちゃいます。 使い方は以下の通り。 提供されているメソッド test( name, test ) : nameにテストの名称、testには実行するテストを関数の形で渡します。 module( name ) : テストの途中で、テスト対象のモジュールや関数の目印を付けたいときに使います。nameにはモジュールの名称を渡します。 ok( state, message ) : stateがtrueならOK、falseならNGという判定になります
継続的なブラウザテストを支援する·Selenium Auto Exec Server MOONGIFT
システムのテストは重要だ。それは分かっていつつも、きちんと的確に行われているケースは数少ない。開発工程の中でも、テストに割り当てられる人員、期間ともに短いのが一般的だ。その中でできるだけテストを行おうと思ったら、自動化は避けられないだろう。 サーバ起動中 だが、自動化されていながらもテストできないのは良くあるケースだ。そこで自動で日々テストを行ってくれるシステムを導入しよう。 今回紹介するオープンソース・ソフトウェアはSelenium Auto Exec Server（以下Selenium AES）、Seleniumを使ったブラウザ自動テストソフトウェアだ。 Selenium AESは、ブラウザテストの自動化ツールであるSeleniumをベースに、テストを自動的に行い、その結果をメールすると言ったことを簡単にできるようにするソフトウェアだ。 ブラウザからのテスト実行 テストケースをSubv
MOONGIFT: » ブラウザをターミナルから操作して自動テストを実現「Firewatir」:オープンソースを毎日紹介
Webアプリケーションのテストは面倒くさい。HTTPでゲットするだけであれば良いが、ポストしたり、JavaScriptでレンダリングしてあったりと、動作も複雑だ。それらを全て網羅的にテストするのはなかなか難しい。 自動操作中 そこでテストにブラウザを使ってみよう。自動操作することで、テストの効率化をはかれる。 今回紹介するオープンソース・ソフトウェアはFirewatir、Firefoxを自動操作するソフトウェアだ。 FirewatirはIEをRubyを使って自動操作するソフトウェア、WatirのFirefox板とでも言うべきソフトウェアだ。実際、読み込むファイル等は違えども全体的な操作はWatirと同じスクリプトで動作する。 操作中のターミナル 実際の使い方はFirewatirの提供するXPIをFirefoxにインストールし、JSSHを起動する。そしてGemを使ってFirewatirをイン
Excelマクロによる、seleniumテストケースの自動生成（1）：CodeZine
はじめに seleniumについての基本的な内容は、以下を参照してください。 Selenium 0.7利用手順書（前編） Selenium 0.7利用手順書（後編） seleniumを利用するメリットとデメリット メリット seleniumを利用する最大のメリットは、「再テスト」が容易になることです。 不具合発生時 テスト担当者と修正担当者の伝達が容易 再テストが容易 仕様変更後 リグレッション（デグレード確認）テストが容易 筆者が特にメリットを感じるのは、テスト担当者と修正担当者の伝達が容易になる点です。テスト期間中は、テスト担当者も修正担当者も作業に追われています。通常、不具合発生時は、テスト実施担当者から修正担当者へ不具合内容を伝達するために、不具合管理ツールなどに、ケース番号や再現手順の詳細を記述、デバッグログの添付などを行い、修正担当者はそれを読み解く必要
第18回 QuickCheckを使ってできることとできないこと
Haskellでは多くの場合，データ駆動型のテスト・ツールであるQuickCheckの方が，xUnitの一つであるHUnitより役立ちます。 ただ，QuickCheckは万能ではありません。場合によってはHUnitの方が有効なこともあります。今回は「QuickCheckでこうしたことはできるのか？」という疑問に一つひとつ答えていきたいと思います。 高階関数をテストできるか？ まず「関数を値に取る関数」，いわゆる高階関数をテストする場合を考えましょう。高階関数((a -> c) -> b)をテストするには，引数になる関数(a -> c)がArbitraryクラスとShowクラスのインスタンスである必要があります。 Prelude Test.QuickCheck> :t quickCheck quickCheck :: (Testable a) => a -> IO () Prelude Te
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Main Page - Test Anything Protocol
TAP, the Test Anything Protocol, is a simple text-based interface between testing modules in a test harness. TAP started life as part of the test harness for Perl but now has implementations in C/C++, Python, PHP, Perl and probably others by the time you read this. Here's what a TAP test transcript looks like (using the development version): TAP version 13 1..4 ok 1 - Input file opened not ok 2 -
メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Marathon Java GUI Test Tool - 2.0 Release - DZone
Google，Cアプリケーションの単体テスト向け軽量ライブラリを発表
JUnitでorg.dbunit.database.AmbiguousTableNameExceptionエラー - プログラマでありたい
