JUnit5で変わるテストの書き方 - きしだのHatena
JUnit5が案外よさげなので、JUnit5を使うとどんな感じでテストが変わるのか考えてみます。 実際にどこが変わったかとか、使い方自体はいろいろまとめられたブログがあるし、公式ドキュメントも読みやすいのでそちらを。 http://junit.org/junit5/docs/current/user-guide/ メソッドごとのテスト JUnit5でいいのは、Nestedですね。 いままで、いろんなメソッドを対象にしたテストが入り混じってたと思います。 import org.junit.Before; import org.junit.Test; public class PurchaseTest { @Before public void setup() { // 全体のセットアップ // purchase()用のセットアップ // history()用のセットアップ } @Test p
JUnitのTheoryテストについて – recompile.net
JUnit 4.4から組み合わせを表現するためのTheoryという機能が導入されています。このTheoryという機能について、日本語での概説がなかったため、調べた範囲で紹介したいとおもいます。 Theoryの実行 Theoryは組み合わせテストのための表現方法です。Theoryを利用するためには、@RunWithアノテーションでTheoriesランナーを指定します。すると、@Theoryアノテーションが指定されたメソッドが実行されます。 @RunWith(Theories.class) public class HelloTheoryTest { @Theory public void helloTheory() { System.out.println("Hello, Theory!"); } } 出力は下記の通りとなります。 Hello, Theory! DataPointの指定 @D
プライベートフィールドに対するテスト | DevelopersIO
クラスメソッドの渡辺です。 弊社では業務時間内にブログを書くことが推奨されており、ネタも何でも良いということで、自動化やユニットテスト関連も投下していきます。今日は結構良く話題に出るプライベートフィールドに対するテストです。 オブジェクト指向プログラミングと可視性 オブジェクト指向プログラミングのひとつの特徴はカプセル化です。簡単に言えば、フィールド（情報）やメソッド（機能や操作）の公開範囲を可能な限り狭くすることで、安全にオブジェクトを扱うことができる、ということです。このため、古典的なJavaのコーディング標準では、次のように、「全てのフィールドをprivateに設定し、必要に応じてアクセサメソッドを定義すること」となっています。 public class Item { private String name; private int price; public String getN
JUnit API探訪：アノテーション一覧 - Diary of absj31
アノテーションについてもひと通り把握しておきたい…と思ったのだが、思ったよりボリューム多めだったのでざっくり調査→行けるところから深堀把握の形と取ろうと思います。一覧の下、個別アノテーションについては自分なりの実践・写経・把握が完了したものから個別エントリに情報をシフト、切り分けて連携していく手法で随時更新して行こうかなと。あまり長引かせずに網羅したいところではあります。 現在、JUnit(4.10)で公開されているアノテーションは以下。 Class Hierarchy (JUnit API) アノテーション説明Blogエントリ 基本 @Test テストメソッドである事を知らせる Blog URL @Ignore テストを無視する Blog URL @RunWith テスト実行時のテストランナを記述 Blog URL テストの前処理・後処理共通化 @Before テストメソッドの前処理：メ
JUnit4のRunner概説 - penultの日記
Runner が何かについては省略。テストの実行のしかたを決めるものと考えればよい。 Runner の指定方法 テストを実行するための Runner を指定するには、基本的にテストクラスに @RunWithアノテーションを設定し、そのパラメータに使いたい Runner のクラスを指定する。 例えば、以下のようにすると Parameterized が使われる。 import org.junit.runner.RunWith; import org.junit.runners.Parameterized; @RunWith(Parameterized.class) public class MyTestClass { ... @Ignore @RunWith 以外で Runner を指定できるケースとして @Ignoreアノテーションがある。 これを指定すると IgnoredClassRunn
JUnit 4 & TestNG
目次 JUnit 4 と TestNG について JUnit 4 TestNG JUnit 4 と TestNG について JUnit 4 は JUnit 3.8 を Java 5 のアノテーションに対応させて各種の制約（テストケースは TestCase を継承する必要があったり、テストメソッドは "test" という名前で始めなければならない）を取り除いたものになっています。若干機能拡張もなされていますが、アノテーション対応が目玉と言って良いでしょう。2006/09/01 現在の最新版は 4.1 です。 TestNG(NG は Next Generation の略)は アノテーションに本格対応したテスティングフレームワークで、JUnit に比べて機能が豊富であることが特徴です。2006/09/01 現在の最新版は 5.1です。 JUnit 4 は Eclipse 3.2 でサポートさ
JUnit のセカイ #JJUG - やさしいデスマーチ
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD（テスト駆動開発）と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit？と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか？JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
hamcrest の Matchers 詳細 - A Memorandum
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
Mockitoノススメ - Fly me to the Luna
モックライブラリ使ってますか? 僕はJavaの人なので、主にJUnitを使ってテストコードを書いています。テストコードを書いている最中、「もしこのオブジェクトから例外が帰ってきたら、ちゃんと例外のハンドリングができてんの？」等々、既存のオブジェクトの振る舞いを差し替えたくなることってありませんか？そういうときにモックライブラリを使うと、既存のオブジェクト処理を差し替える事ができます。 実は最初はモックライブラリって意味あるの?と懐疑的だったんです。どういうところに懐疑的だったかというと、 テストコード中に出てくるモックライブラリのセットアップがめんどい。 テストコードがプロダクトコードの実装に依存しちゃうんじゃないの？プロダクトコードをちょっと変えただけでテストが落ちるようになるんじゃないの？ みたいなところです。でもMockitoというモックライブラリを使ってテストコードを書き初めてから
Quick JUnit Plugin for Eclipse
2013/04/25: プロジェクトの構造を改善しました。 2012/04/25: 0.7.0をリリースしました。詳しくはリンク先の変更履歴をご覧ください。 2011/04/25: 0.6.0をリリースしました。詳しくはリンク先の変更履歴をご覧ください。 2010/04/25: 0.5.0をリリースしました。詳しくはリンク先の変更履歴をご覧ください。 2010/01/01: beta3をリリースしました。詳しくはリンク先の変更履歴をご覧ください。 2009/10/13: Beta版配布用更新サイトをsourceforge.jpに用意しました。また、実験版にMacではキーバインドが変更されているバグがあったので、修正し、beta2をリリースしました。 2009/05/09: Eclipse 3.5系だとインストールできなかった問題に対応しました。 2009/04/25: 実験的な機能としてT
【コラム】イマドキのIDE事情 (106) ユニットテストを支援するEclipseプラグイン | エンタープライズ | マイコミジャーナル
テストケースの作成を支援するEclipseプラグイン JavaではJUnitを用いてユニットテストを自動化するテスト手法が広く普及している。JUnitではテストケースをJavaプログラムとして記述しておくことでテストを自動化するため、一度テストケースを書いてしまえば再テストの手間もかからないため、回帰テストが必要となるケースでは特に有効だ。テスティングフレームワークを用いたユニットテストの自動化はJava以外のプログラミング言語でも一般的な手法となっている。 しかし、一般的にテストケースのコード量はテスト対象のコードと同じかそれ以上になると言われており、テストケースの作成にはそれなりの時間を要する。このためユニットテストの整備がついつい後回しになってしまうケースも多いのではないだろうか。 今回はEclipse上でJUnitによるユニットテストの作成・実行を支援するEclipseプラグインと
hamcrestのMatcherメモ - 都元ダイスケ IT-PRESS
技術ネタじゃないところで盛り上げてしまった。技術ネタいこう、技術ネタ。 さて、JUnitを使う際、hamcrestライブラリを使って、英語として読めるようなassertionを書く、なんてのは流行ってたり流行っていなかったり？ JUnit4限定だけれど、assertionの際、assertEqualsとか色々assertionのメソッドはあるけど、全てassertThatで書くことができるはず。assertThatメソッドの第一引数にテスト対象、第二引数にhamcrestのMatcherインターフェイスの実装を与えます。なんのこっちゃですが。 Jiemamyでは、なるべくassertThat以外のassertionメソッドを使わないようにテストを書いています。（もしかしたらもう一つも残ってないかも。） まぁ、以下のように書くと、英語っぽいのが書けますよ、と。 assertThat(aaaa
Google App Engine上でJUnitを実行する·Kotori Web JUnit Runner MOONGIFT
Kotori Web JUnit RunnerはGoogle App Engine用/Java製のオープンソース・ソフトウェア。Google App EngineではJavaが選択できるようになったことで開発者の裾野が大きく広がった。開発からデプロイまでスムーズに連携し、とても便利なプラットフォームと言えるだろう。 テストを選んで実行 だがGoogle App Engineは通常のホスティングサービスと異なり様々な制約がついている。そのため手元の環境では動いてもサーバ上にデプロイすると動かない、なんて問題も発生する。そこで使っていきたいのがKotori Web JUnit Runnerだ。 Kotori Web JUnit Runnerはローカルはもちろん、Google App Engine上にデプロイした状態でもJUnitを実行できるソフトウェアだ。画面は二分割されており、左側でテストを
junitで例外のテストをもっと簡単にしたい - Sacrificed & Exploited
最近のJunitでは例外のチェックが前よりは簡単になったけど、JDaveの匿名クラスを使った記述方法と比べていまいちだなと感じていた。 例外のチェック方法の比較 JUnit4での例その1:@Testのexceptionを使う場合。 「JUnit Cookbook」より @Test(expected= IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0); } JUnit4での例その2:@Ruleを使う場合。 「http://kentbeck.github.com/junit/javadoc/latest/org/junit/rules/ExpectedException.html」より。 // These tests all pass. public static clas
JUnitの新しいアサーション assertThat - A Memorandum
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
JUnit4.7 の新機能 Rules とは - A Memorandum
Rules とは JUnit4.7から@Ruleアノテーションが追加されました。@Ruleアノテーションは、org.junit.rules.MethodRuleインターフェースのサブクラスによって定義された振る舞いをテストメソッドに追加します。 MethodRuleの組み込み実装クラス MethodRuleの具象クラスとして、以下のクラスが提供されています。 MethodRule ├ Verifier : オブジェクトの状態が不正な場合にテストを失敗させる │ └ ErrorCollector : 1つのテストメソッドの複数のエラーを集集する ├ ExpectedException : スローされた例外について柔軟なアサーションを行う ├ ExternalResource : サーバの起動停止などの外部リソースの操作を行う │ └ TemporaryFolder: テストメソッド前に一時フ
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
- JUnit 実践講座
更新: 2003/11/05 公開: 2002/01/03石井 勝 はじめに ここでは， JUnit ついて僕が普段使っているテクニックやコーディングスタイルについてまとめていきたいと思います．読者としては，ある程度 JUnit を使いこなせる方を想定しています． 僕が仕事で JUnit を使い始めて 1 年半以上になります．つい先日まで行っていた開発プロジェクトでは，テストメソッドの数は 2000 程度，TestCase のクラス数は 2,3 百個という規模になりました．それぐらいの規模になれば，JUnit でコーディングする際に何らかの指針が必要になります．その開発プロジェクトでは，何度もプログラミングスタイルを変え，どういうスタイルが JUnit のコードをメンテナンスしやすいか，ということを考えてきました．そういったことをまず プログラミングスタイルガイド と シナリオベースのテス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
Google Code Archive - Long-term storage for Google Code Project Hosting.