第4回 渋谷java http://connpass.com/event/3744/ でお話した「JUnit のオブジェクト等価比較を怠けたい!」の発表資料です。発表で使用するはずだったデモコードは https://github.com/komiya-atsushi/shibuya-java4 こちらの…

id: 1141 所有者: msakamoto-sf 作成日: 2013-01-14 18:36:28 カテゴリ: JUnit Java TDD TestNG [ Prev ] [ Next ] [ 技術 ] JUnit実践入門(初版)での JUnit 4.10 をベースに、書籍で紹介されている主要なJUnitの機能が TestNG 6.x で提供されているか比較してみました。 JUnit http://junit.sourceforge.net/ TestNG http://testng.org/doc/index.html ※全JUnit4.x系と全TestNGの6.x系のすべてのchangelogやコード、JavaDocを精読して調査したわけではありません。Googleでざっくりと検索した結果のまとめ記事になります。JUnit4.x系も、TestNG6.x系もそれぞれ活発に開発が続け
テストメソッド名を日本語で書きたい。 実線がYes, 点線はNo. 補足 テストコードが納品物になってないとかで軽視されている場合は、自身に対するわかりやすさ重視で日本語。 テストコードの価値がそれなりに認められている場合は、自分以外に少なくとももう一人日本語メソッド名に共感している人が欲しいです。布教して増やすでもオーケー。独り善がりは無し。 めげないってのはレポートとかが文字化けしたときに何らかの手段で対抗できる人かどうかです。自己解決できない人に無理に押しても不幸になるだけなので、その辺を片付けられるようになってから。 ポイントはJavadocが日本語かどうか。日本語メソッド名が効果を持つのは、そのコードを日本語を解する人が触る場合です。そうで無い人が触ることを想定してテストメソッド名は英語にするべきとか言うなら、javadocも英語にしていて然るべきです。Javadocが日本語なら
寂しがりだから Hamcrest と一緒に使ってあげてね。 やってみる こんな風に書いて。 import org.junit.*; import static org.junit.Assert.*; public class HogeTest { @Test public void hoge() { fail("しぱーい"); } } こうして。 $ javac -cp junit-4.11.jar HogeTest.java $ ls HogeTest.class HogeTest.java junit-4.11.jar だーん。 $ java -cp ./junit-4.11.jar:. junit.textui.TestRunner HogeTest .F Time: 0.003 There was 1 failure: 1) warning(junit.framework.Test
Java, Cayenne, jMockjMockの使い方を,いまさらながら調べたのでメモ的に記録しておきます。 ORマッピング・フレームワークであるApache Cayenneでは,多くのORマッパと異なり,データオブジェクト(エンティティ)がインタフェースを使っていません。Cayenneはバイトコード・エンハンスとかを使用しない作りなので,継承関係を用いてデータオブジェクトの機能が提供されてます。で,このデータオブジェクトのテストを実行する際にモックを使いたいのだけど,インタフェースがないからどうしよう,という話がありました。 答えは簡単な話で,ほとんどのモック・ライブラリは実クラスのモック化をサポートしています。今回はjMockを使いました。easyMockでも同じようなことは可能でしょう。pom.xmlへのライブラリの追加次のライブラリをMavenのpom.xmlに追加します。 o
更新: 2003/11/05 公開: 2002/01/03石井 勝 はじめに ここでは, JUnit ついて僕が普段使っているテクニックやコーディングスタイルについてまとめていきたいと思います.読者としては,ある程度 JUnit を使いこなせる方を想定しています. 僕が仕事で JUnit を使い始めて 1 年半以上になります.つい先日まで行っていた開発プロジェクトでは,テストメソッドの数は 2000 程度,TestCase のクラス数は 2,3 百個という規模になりました.それぐらいの規模になれば,JUnit でコーディングする際に何らかの指針が必要になります.その開発プロジェクトでは,何度もプログラミングスタイルを変え,どういうスタイルが JUnit のコードをメンテナンスしやすいか,ということを考えてきました.そういったことをまず プログラミングスタイルガイド と シナリオベースのテス
最近新人のコードレビューをする機会が増えまして、自分の中の経験則を言語化する機会に恵まれています。なんとなーくわかっていた事柄を人に伝えようとするのは、いつの時代にも最良の学びの機会ですね。 さて新人各位に個別に伝えた「JUnit4利用に関する注意」を整理してみました。JUnitは自由度の高いフレームワークであり使い方は十人十色かと思いますので、もっと良い使い道をご存知のかたは是非はてブコメントなどで教えていただければと思います。ちなみにここで言う「テスト」とは実装の前に書く単体テストだけではなく、実装後に書かれるものや自動化された統合テストも含めています。 1.JUnitを使うために押さえるべき前提知識 テストメソッドの実行される順番は不定 EclipseのJUnit実行機能に親しんでいると意外と気付けないのですが、JUnitはテストクラス内のテストメソッド実行順を保証していません。それ
2013/11/28 新機能および新端末追加のお知らせ 2013年11月28日(木)実施のシステムメンテナンスが終了いたしましたのでご報告いたします。 尚、メンテナンス完了に伴い新規機種・機能を追加いたしました。 下記のとおり 1. Android 4.4に対応 Remote TestKitがAndroid 4.4(KitKat)に対応しました。 あわせてレンタルできる端末にNexus 5を追加いたしました。 2.新規機能追加 自動キャプチャ ファーストビュー機能 「複数端末同時操作」による画像保存時にページ全画面のキャプチャに加え、端末ディスプレイに最初に表示される画面を同時に保存する機能を追加いたしました。 本機能によりレンタルした端末でWebページの確認をする際に1画面に表示される範囲がひと目で確認できるようになりました。 3.レンタル端末の新規追加 最新端末の追加 ご要望にお答えし
Java Advent Calendar 2011の16日目です。 前:JSFUnitでテストしよう! | Kokuzawaの日記 次:JavaEE使ってウェブアプリケーションつくろうよ - 水まんじゅう 書いてること JUnit の話です。使い始めからちょっとだけ踏み込んだ辺りですかね。ちょっとだけなので普通に使ってる方には不要な内容かと思います。私の今持ってる知識を書き殴ってみた感じになりましたが、微妙な理解と残念な文章力の相乗効果でグダグダになってます。お察しください。 内容は Assertion->カスタムAssertion、Matcher->カスタムMatcher、Rule->カスタムRule です。 Assertion JUnitは assert があってこそです。まず org.junit.Assert にある馴染み深い assert を並べてみます。 assertEquals
JavaでTDDBCに参加し、Bootはした。となると次はBoostしていく必要が出てくる訳だが、職場や社外で実践経験を積むのと同様、JUnitやJavaでのテスト実行に関しての知識も増やしていく必要があるのでは?と思い立ち、このタイミングで有用なネタを集めてみました。 Groovy/G*界隈でBoostする為に有用なリンクを集めてみた(Groovy編) - Shinya’s Daily Report Groovy/G*界隈でBoostする為に有用なリンクを集めてみた(Gradle編) - Shinya’s Daily Report Groovy/G*界隈でBoostする為に有用なリンクを集めてみた(Spock編) - Shinya’s Daily Report テーマによってはひとまず項目のみ洗い出し、項目別に写経や深掘り調査を行った後にエントリとしてUPして行こうと思います。 JUni
blog1.mammb.com では CoreMatchers についてでしたが、こちらでは org.hamcrest.Matchers についてまとめます。 org.hamcrest.Matchers JUnit についてくるのは org.hamcrest.CoreMatchers で基本的な Matcher が提供されています。org.hamcrest.Matchers は CoreMatchers を機能拡張したものとなってます。CoreMatchers にあるメソッドは、Matchers にもあります。 hamcrest-core − org.hamcrest.Matchers が入ってる hamcrest-library − org.hamcrest.Matchers が入ってる hamcrest-library は以下のようなパッケージ構成となっており、各用途に応じた Ma
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"));
JUnit Hamcrest on eclipse eclipse の JUnit サポートに そろそろ Hamcrest の static インポート設定入れて欲しいところです。環境変わると設定箇所探すのに戸惑うので・・ ということでメモ。 Content Assist Favorits 設定画面で、Java - Editor - Content Assist - Favorits にて以下の設定。 New Type org.hamcrest.CoreMatchers org.hamcrest.Matchers (hamcrest-library利用時) New Members org.junit.Assert.assertThat org.junit.Assert.fail こんな感じです。 JUnit の jar だけ使うなら org.hamcrest.Matchers の指定は不要
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のコードを書くことが習慣となっていると、値の検証はassertEquals(期待値, 実際値)メソッドで行うというというのがずっと常識となっていました。しかし、4年ほど前にリリースされたJUnit4.4以降では、長年親しんできたassertEquals()に加えて、新しくassertThat()と呼ばれる別の検証メソッドが追加されています。この新しい検証メソッドについては、既にいくつかのサイトで説明されています。 http://journal.mycom.co.jp/articles/2007/07/20/junit1/index.html 林檎生活100: JUnit 4.4 の機能,assertThat と Assumptions,Theories について. hamcrestのMatcherメモ - 都元ダイスケ IT-PRESS hamcrest の Co
単体テストを“神速”化するQuick JUnitとMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
テストケースの作成を支援するEclipseプラグイン JavaではJUnitを用いてユニットテストを自動化するテスト手法が広く普及している。JUnitではテストケースをJavaプログラムとして記述しておくことでテストを自動化するため、一度テストケースを書いてしまえば再テストの手間もかからないため、回帰テストが必要となるケースでは特に有効だ。テスティングフレームワークを用いたユニットテストの自動化はJava以外のプログラミング言語でも一般的な手法となっている。 しかし、一般的にテストケースのコード量はテスト対象のコードと同じかそれ以上になると言われており、テストケースの作成にはそれなりの時間を要する。このためユニットテストの整備がついつい後回しになってしまうケースも多いのではないだろうか。 今回はEclipse上でJUnitによるユニットテストの作成・実行を支援するEclipseプラグインと
技術ネタじゃないところで盛り上げてしまった。技術ネタいこう、技術ネタ。 さて、JUnitを使う際、hamcrestライブラリを使って、英語として読めるようなassertionを書く、なんてのは流行ってたり流行っていなかったり? JUnit4限定だけれど、assertionの際、assertEqualsとか色々assertionのメソッドはあるけど、全てassertThatで書くことができるはず。assertThatメソッドの第一引数にテスト対象、第二引数にhamcrestのMatcherインターフェイスの実装を与えます。なんのこっちゃですが。 Jiemamyでは、なるべくassertThat以外のassertionメソッドを使わないようにテストを書いています。(もしかしたらもう一つも残ってないかも。) まぁ、以下のように書くと、英語っぽいのが書けますよ、と。 assertThat(aaaa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く