JaSST'11 Niigata は約60名にのぼる方々に参加いただき、盛況のうち終了しました。 ご参加、ご協力いただいた皆様、有難うございました。 基調講演 事例発表１ 事例発表２
JaSSTソフトウェアテストシンポジウム-JaSST'11 Niigata
JaSST'11 Niigata は約60名にのぼる方々に参加いただき、盛況のうち終了しました。 ご参加、ご協力いただいた皆様、有難うございました。 基調講演 事例発表１ 事例発表２
第1回 レガシーコード前夜 | gihyo.jp
はじめに 「レガシーコード」――この言葉を聞いて何を思い浮かべますか？ もしかしたら、COBOLで書かれたコード、Windows NT 4.0用のコード、書いた人がわからなくなってしまったコードなどが思い浮かぶかもしれません。 しかし、このレガシーコードをメインテーマとして正面から扱っている書籍『Working Effectively with Legacy Code』（WEwLC ※1）では、レガシーコードについて異なった見解を示しています。そう、「明日自分の書くコードもレガシーコードになるかもしれない」というWEwLCが発するメッセージは、私たちに切実に迫ってくるのではないでしょうか。 この連載では、WEwLC読書会の有志が、WEwLCが語りかけるものや、現実の課題への活かし方などを対談形式で紹介していきます。この本が発するメッセージについては連載の中でおいおい明らかにしていきたい
ユニットテストの保守性を作りこむ, xpjugkansai2011
3. 自己紹介 • 井芹洋輝（いせりひろき） • 扱っているもの – 組込み開発/ソフトウェアテスト/開発者テスト • 所属 – WACATE実行委員/TDD研究会/ATECなど • 対外活動 – JaSST’11 Tokyo/WACATE2011冬/Androidテスト祭り等 – ソフトウェアテストPRESS総集編/Ultimate agile Stories
JavaScriptのテストについて本気出して考えてみた(2) - 愛と勇気と缶ビール
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか？Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
JavaScriptのテストについて本気出して考えてみた(1) - 愛と勇気と缶ビール
一週間のうちまる一日くらいは、「あーあのJavaScriptコードのテストってどうするのがいいかしら？」と考えている。 嘘です。多分45分くらい。 考えている時間の長さはどうでもいいんだけど、JavaScriptのテストは場合によっては中々ややこしい問題に成り得る。DOMなどの外部リソースにタッチすることのない「純JavaScript（オレオレ用語です）」であればブラウザ上であろうとRhino上であろうとNode JS上であろうと(理論上は)テストを動かせるのだが…。 JavaScriptであろうとなかろうと、外部のリソースに依存している（外部のリソースを操作する）コードはそうでないコードよりテストが面倒になる。ファイルR/WやDBの操作などIO系は勿論そうだし、どこかのサーバに何かしらのプロトコルで話しかけるようなコードもしかり。 JSのテストがややこしくなるのは、JavaScriptの
拡張型TDD on JaSST2011Tokyo
JaSST 2011 Tokyoでの「新しいTDDアプローチ TDDの新しい活かし方をライブで見せます！」に関連したつぶやきを集めています。 見落としや、関係ないものが混ざっていたらすみません。追加や修正していただけるとありがたいです。
JMockitは理想的なモックフレームワーク - かとじゅんの技術日誌
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
"Excelenium"（エクセレニウム）で，快適な自動回帰テストを （Seleniumのテストスクリプトとテスト仕様書を自動生成） - 主に言語とシステム開発に関して
テスト仕様を書くだけで，仕様書自身がテストを自動でやってくれる。 それがExcelenium（エクセレニウム）。 Excelenium ＝ Excel ＋ Selenium 左側で，操作のステップを日本語で書くと， 右側で，テスト仕様書風のフォーマットの文章をリアルタイムで自動生成してくれる。 ※画像中で「確認」と書いてあるのは，チェックポイントの部分。これは自動的にオレンジ色のセルになる。 書く必要があるのは，青い線より左側だけ。 そして， 「この仕様書の全テストを実行」 というボタンを押すと・・・ Seleniumのテストケースが自動生成され， ブラウザが立ち上がり， テスト仕様書に書いてあった全テストが実行される。 （※ついでに，シート上の全テストケースに自動で番号が振られる。） Webアプリケーションの結合テスト / 回帰テストが大幅に楽になる。 従来のような「テスト仕様書」と称し
Free Web Hosting - Your Website need to be migrated
check Unlimited Number of Websites check Unlimited Email Accounts check Unlimited Bandwidth check 2X Processing Power & Memory check LiteSpeed Cache check WordPress Acceleration (LSCWP) check Cloudflare Protection check Github Integration check 24/7/365 Support check Easy Website Builder check 99.9% Uptime Guarantee check DNS Management check Unlimited MySQL Databases check 100 Subdomains check Un
StrutsのActionをMockitoを使ってUnitTestする #javaadventja2010
このエントリは Java Advent Calendar -ja 2010 : ATND の 5日目のものです。 やぁ、みなさんStruts使ってますか！最近「いつまでStruts1を使い続けるの？ - 達人プログラマーを目指して」とか「Strutsの終焉: プログラマの思索」とかで、何かと話題のStruts1ですが、もろもろの事情で使わなければいけないことって多いですよね？ね！ で、仕方なく使わざるを得ないStrutsですが、ActionのexecuteメソッドがそのままだとJUnitなんかでUnitTest(できない|できても大変)で困ります。 そんな時は、Mockを使ってテストしましょう！今回はMockitoを使います。 こんなActionがあったとして。 package com.example.masaru.action; import javax.servlet.http.Htt
コードカバレッジのまとめ - ソフトウェアテストの勉強室
単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。 2008/03/12更新 サンプルプログラムで解説を追加 サンプルプログラムは、以前例題として作成したテニスのスコアボードについて [例題]テニスのスコアボード ステートメントカバレッジ 命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準で
ソフトウェアテスト入門(2)
ソフトウェアテスト入門(2) 2007/12/20 ディノ 竹腰彰成 前回の内容（１） テストの目的とは ◦ バグ出し・品質保証 ◦ 品質保証したい対象ごとにテストがある 演習問題 テスト技法 ◦ ブラックボックステスト 同値分割 境界値分析 前回の内容（２） 同値分割 ◦ 入力値を意味ごとに分割 「英字のみ受付」→ 有効値：英字 無効値：記号など 境界値分析 ◦ 処理が変わる境目に着目 「１ページ５件」→ ５件と６件で確認 ポイント もれなく・効率的に 今日の内容 テスト技法 ◦ ブラックボックステスト （同値分割） （境界値分析） デシジョンテーブル 原因結果グラフ 前回の内容 今回の内容 デシジョンテーブル ブラックボックステスト デシジョンテーブル Decision：意思決定、決断、判定 「決定表」とも言う 組み
心地良すぎるモックライブラリ Mockito 〜その3〜 - A Memorandum
モックメソッドからの戻り値のデフォルト設定(Since 1.7) 引数をキャプチャしてアサーションで利用する(Since 1.8.0) 部分的に実メソッドを呼び出すモック(Since 1.8.0) モックのリセット(Since 1.8.0) 振舞駆動開発のためのエイリアス(Since 1.8.0) serializableモック(Since 1.8.1) 新しい@Captor, @Spy, @InjectMocks アノテーション(Since 1.8.3) タイムアウト検証(Since 1.8.5) 本記事は、以下の記事の続きです。 blog1.mammb.com モックメソッドからの戻り値のデフォルト設定(Since 1.7) モックメソッドからのデフォルトの戻り値を、モック定義時に Answer として指定することができます。組込で定義されている Answer を使用ることも Foo
心地良すぎるモックライブラリ Mockito 〜その2〜 - A Memorandum
呼び出し順序の妥当性検証 余計なメソッド呼び出しが行われていないことを検証する Mockito のアノテーション 複数回のモックメソッド呼び出しの結果を変化させる コールバック付きの戻り値定義 voidメソッドの振舞を定義するdoXXファミリー 実オブジェクトの動作を変えるspy 本記事は、以下の記事の続きです。 blog1.mammb.com 呼び出し順序の妥当性検証 以下のように、2つのモックがあり、それぞれのモックの add() メソッドの呼び出し順序を検証したい場合、 List firstMock = mock(List.class); List secondMock = mock(List.class); firstMock.add("was called first"); secondMock.add("was called second"); InOrder を使用します。
心地良すぎるモックライブラリ Mockito 〜その1〜 - A Memorandum
EasyMockとの違い Eclipse での利用に際して org.mockito.Mockito モックの利用と妥当性検証 スタブメソッドの定義 引数の照合 メソッド呼び出しの妥当性検証 voidメソッドから例外を返却 API的に EasyMock と大きな違いはありませんが、使用感としては格段に心地良い Mockito。 [:W150] 本家 http://mockito.org/ のドキュメント(というかJavaDoc)をベースにメモ。 EasyMockとの違い Mockito では record モードと replay モードを切り替える必要がない Mockito で作成するモックは常に、EasyMock で言う NiceMock となる スタブメソッドの妥当性検証が常にオプション扱い 大きくは以上となります。具体的に、EasyMock では import static org.e
hamcrest の CoreMatchers 詳細 - A Memorandum
blog1.mammb.com のついでに hamcrest の CoreMatchers についてまとめます。 Matchers については blog1.mammb.com まずは基本の is と not 全体的にはこんな感じ。 import static org.hamcrest.CoreMatchers.is; import static org.junit.Assert.assertThat; import org.junit.Test; public class FooTest { @Test public void testFoo() { String actual = "foo"; assertThat(actual, is("foo")); } } not はこう。 String actual = "foo"; assertThat(actual, not("bar"));
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】DevLOVE Test Dayでお話しました
はてなブログ | 無料ブログを作成しよう
Grails Gets Some FitNesse Finesse | Groovy Zone