Javaでのデータベースのテストデータ作成にはDBUnitがよく使われますが、自分はDbSetupをオススメします。 DbSetup なぜDBUnitがイマイチなのか 自分も最初はDBUnitを使ってたのですが、以下の理由からしっくり来ませんでした。 DBを使ったテストでは少量のデータを使うことが多い ホワイトボックステストで大量のデータを使うことはほとんどなく、単一または複数のテーブルに対して、少量のデータを用意するケースがほとんどです。なので、テストごとにファイル(XML or Excel)を用意するのは面倒です。 テストコードとデータが分離している テストデータを外部ファイルに保存するため、テストコードとテストデータが分離してしまっています。そのため、何をテストしているのかが分かり辛いです。 そこでDbSetup そこで見つけたのがDbSetupです。DbSetupはテストデータをJ
JMockit の使い方メモ。 まとめといて何だけど、 JMockit が提供している強力な機能はなるべく使わないで済むように設計（実装）することが、理想的なんだろうなと思うわけです。 （たぶん、 JMockit の機能を下手に使いすぎると、可読性が落ちて、テストコードのメンテナンスも大変になりそうな気がする） でも、いざテスト困難な実装とぶち当たったときに備えて、ひと通り機能は知っておいた方がいいとも思うわけです。 ※このメモは ver1.6 の頃のもので 2016年 12 月現在の最新（ver 1.29）とは異なる点が多数あると思われます。JMockit は API の非推奨化→削除もかなり頻繁に行われているようなので、中には最新版では使えなくなっているものもあるのでご注意ください。 #環境 ##Java 1.7.0_40 ##JMockit 1.6 ※一部 1.21 で確認 #インス
テストを書くことは良い事です。どんどん書いて品質を上げたいところではありますが、テストの数が数万〜数十万に及ぶようなプロジェクトでは、フルテストに要する時間が無視できない程膨れ上がってしまいます。 今回は、そんな増えすぎたテストコードの影響でフルテストに時間がかかっているプロジェクトのために、テスト高速化を実現するためのモジュールとその使い方について紹介したいと思います。 モジュールは、App::Ikarosというもので、現在version 0.02がリリースされています。 使い方等はここにまとめてあるので(随時更新する予定)、この記事ではどのようなことができるモジュールなのかをざっと説明しようと思います。 まず、ざっくりとですがApp::Ikarosが提供する機能には以下の様なものがあります。 多数のノードによる分散テスト実行 forkproveによるテスト実行の高速化 Devel::C
JUnitをより深く知っていこう。と言う事で本丸JUnitのクラスから幾つか機能を探訪していこうかと思います。 org.junit.Assertクラス Assert (JUnit API) 主なメソッドは以下の通り。 メソッド 説明 assertArrayEquals(arrays expected, arrays actual) 配列同士を比較、イコールである場合true assertEquals(Object expected, Object actual) オブジェクト同士を比較、イコールである場合true assertFalse(boolean condition) 条件がfalseである事を検証、falseの場合true assertNotNull(Object obj) オブジェクトがNullで無いことを検証、Nullでない場合true assertNotSame(Object
AWSチームに参画して2ヶ月ほど経ちました。ところが、AWSの構築などにはあまり関わらず、ひたすらAWSに関連するプロダクトの開発を行う毎日です。そんな折、ボスより次のようなリクエストをいただきました。 ユーザが参照できない情報について、参照できないことを検証して欲しい ・・・「出来ないことの検証」です。 「出来ることの検証」であれば、その例をテストケースとして記述してテストを実行すれば検証出来ます。しかし、出来ないことを証明することは非常に困難です。ただ、情報は有限なんで、総当たりにでもやればできるかもしれません。 ！？ システムのインフラは当然のようにAWSです。テストのためのリソースが足りなければ増やせばいいじゃないですか。時間がかかるならば並列化すればいいじゃないですか。テストの時だけ増やせばいいんです。 ならば、総当たりでテストしよう という方針になりました。そして、ブログのネタ
渡辺です。 先日、「JUnitのオブジェクト等価比較を怠けたい!」というスライドが公開されました。「オブジェクトのカスタムアサーションをどのように実現するか」という問題は、ユニットテストを実践していくとよく発生します。この問題に関して、先日のJJUG CCCでも相談されました。また、簡単に書ける仕組みは共有した方が良いのですよね。そんなわけで、cmtestというライブラリにまとめましたので紹介したいと思います。 Objectクラスのequalsメソッド Javaではオブジェクト同士の比較にはObjectクラスのequalsメソッドを利用することが定石です。これはユニットテストのアサーションでも同様です。テストした結果に作られる実測値と、テストの期待値を比較する時、通常はequalsメソッドを利用します。equalsメソッドを使った比較を行うのであれば、定番のassertThat構文を利用で
Junit4.4から assertThat というアサーションメソッドが追加された。 APIの定義は以下の通り。 public static <T> void assertThat(T actual, org.hamcrest.Matcher<T> matcher) public static <T> void assertThat(java.lang.String reason, T actual, org.hamcrest.Matcher<T> matcher) 以下の様に、英語として読みやすい記述でアサーションを記述できる。 import static org.hamcrest.CoreMatchers.*; public class Test1 { @Test public void test() throws Exception { assertThat(Integer.pars
JUnit 実践講座 - シナリオベースのテストケースの書き方 2002/02/03 作成 石井 勝 目次 はじめに メソッドベースとシナリオベース サンプルプログラム - LoginFormTest クラス scenario メソッド verify メソッド Scenario インナークラス テストに応じてスタイルを変えよう シナリオベースの問題点について 特殊解をあらわにするヘルパーメソッド はじめに ここでは，テストケースの具体的な書き方として，シナリオベースのテストケースを紹介します．プログラミングスタイルガイド で述べたように，実際の開発ではテストコードはかなりの規模になります．どうしたらテストコードを読みやすく，メンテナンス性を上げることができるのでしょうか？ …僕には，まだこの問題に対する満足な答えを得ることができません．しかし，シナリオベースでテストケースを書けば，場合によ
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
毎年４月２５日はQuick JUnitにとって大切な日です。毎年β版をリリースし続けているのもあれなので、リリース版とするために懸案だったMacOSX上でテストメソッド名が日本語メソッド名だと起動しない問題に挑戦しました。調べてみると、その原因はQuick JUnitに原因があった訳ではありませんでした。そもそもMacOSXのEclipse環境だと、日本語が通らないことって多くないですか？ということで、原因と対策についてつらつらとまとめます。自分がMacOSXを開発環境として使用し始めたのはここ数日なんで、詳しくはわかりません。ので、もし違っていることがあればコメントなりブコメをいただけるとありがたいです。 原因はMacOSX上のJavaのデフォルトエンコードにある模様 MacOSX上のJavaはApple謹製のJDK,JREな訳ですが、デフォルトエンコードがJDK5の時はUTF-8だった
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
