ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
JUnitでテスト後にディレクトリを自動削除する機能を使う(Rules) - argius note
比較的新しいJUnitでは、TemporaryFolder(org.junit.rules.TemporaryFolder)というRuleクラスが使用できます。 テストで使った一時ディレクトリを、テストが終わった後に自動で消すことができます。 Rulesの機能は、2009-08-04にリリースされたJUnit4.7で追加されています。 Javaで一時ディレクトリを使うには JUnitとは関係なしに、Javaで一時ディレクトリを使う場合は、システムプロパティ"java.io.tmpdir"を参照します。 この値は、Windowsなら通常は環境変数"TMP"と同じ値が設定されています。 また、File.createTempFileメソッドを使えば、この一時ディレクトリに自動で一時ファイルを作ることができます。 File tmpfile = File.createTempFile("myprod
ブラックボックステストとホワイトボックステスト | DevelopersIO
テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか？ それともブラックボックステストでしょうか？ 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行
JUnitのassertThatのいいところ - きしだのHatena
JUnitでのテストでは、古くは次のように書いてました。 assertEquals("期待値", "実際の値"); で、比較の種類だけassertXxxがあるわけです。 最近だと assertThat("実際の値", is("期待値")); のようにも書けます。 別にどっちでもええやん、とか思ってたのですけど、最近はassertThatのほうを使うようになりました。 というのも、assertEqualsを使おうとすると、補完で結構下まで移動する必要があったのです。 これがassertThatなら、次のようなstatic importにしておけば「as」で補完しても最初にassertThatが出てきます。 import static org.junit.Assert.assertThat; CoreMatchersも次のようにimportしておく必要がありますが、「is」とかは補完するまでも
DbUnitのためのRuleから、RuleChainとかその辺の話 - 日々常々
JUnit実践入門の「第12章 データベースのテスト」でも取り上げられているDbUnitさんのRuleから派生して、RuleとかRuleChainとかその辺をちょっと書いておきます。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (68件) を見る セットアップ ざくっと使えるようにするための build.gradle はこんな感じ。Mavenでもだいたいわかりますよね。 apply plugin: 'java' repositories.mavenCentral() dependencies { testCompile 'com.h2database:h2:1.3.170'
『JUnit実践入門』写経・実践会 in 横浜 #4 を開催してきた #junitbook - Diary of absj31
『JUnit実践入門』写経・実践会 in 横浜 #3 - connpass 2013/03/03 『JUnit実践入門』写経・実践会 in 横浜 #4 #junitbook - Togetter 前回第3回からほぼ1ヶ月後の開催となった第4回。対象は『第12章 データベースのテスト』。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (69件) を見る 第1回 『JUnit実践入門』写経・実践会 in 横浜 #1 を開催してきた #junitbook - Shinya’s Daily Report 2012/12/01 『JUnit実践入門』写経・実践会 in 横浜 #1 #j
新人に話したJUnitのための知識とTips : toda_k
最近新人のコードレビューをする機会が増えまして、自分の中の経験則を言語化する機会に恵まれています。なんとなーくわかっていた事柄を人に伝えようとするのは、いつの時代にも最良の学びの機会ですね。 さて新人各位に個別に伝えた「JUnit4利用に関する注意」を整理してみました。JUnitは自由度の高いフレームワークであり使い方は十人十色かと思いますので、もっと良い使い道をご存知のかたは是非はてブコメントなどで教えていただければと思います。ちなみにここで言う「テスト」とは実装の前に書く単体テストだけではなく、実装後に書かれるものや自動化された統合テストも含めています。 １．JUnitを使うために押さえるべき前提知識 テストメソッドの実行される順番は不定 EclipseのJUnit実行機能に親しんでいると意外と気付けないのですが、JUnitはテストクラス内のテストメソッド実行順を保証していません。それ
- JUnit 実践講座
更新: 2003/11/05 公開: 2002/01/03石井 勝 はじめに ここでは， JUnit ついて僕が普段使っているテクニックやコーディングスタイルについてまとめていきたいと思います．読者としては，ある程度 JUnit を使いこなせる方を想定しています． 僕が仕事で JUnit を使い始めて 1 年半以上になります．つい先日まで行っていた開発プロジェクトでは，テストメソッドの数は 2000 程度，TestCase のクラス数は 2,3 百個という規模になりました．それぐらいの規模になれば，JUnit でコーディングする際に何らかの指針が必要になります．その開発プロジェクトでは，何度もプログラミングスタイルを変え，どういうスタイルが JUnit のコードをメンテナンスしやすいか，ということを考えてきました．そういったことをまず プログラミングスタイルガイド と シナリオベースのテス
技術/TDD/JUni 4.10 と TestNG 6.x系 機能比較(by JUnit実践入門) - Glamenv-Septzen.net
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系もそれぞれ活発に開発が続け
今から５分で，開発中のAndroidアプリを単体テストしよう （JUnitで自動テストする方法） - 主に言語とシステム開発に関して
AndroidプログラミングのTOPへ 開発中のAndroidアプリを，単体テストフレームワークJUnitを使ってテストする。 Eclipse上で，サンプルアプリを作り始めてから， アクティビティ内のロジックやUI操作をテストする所までを５分で行なう。 早ければ３分。 記事の末尾には，Androidアプリの自動テストに役立つ情報を集約したリンク集を掲載。 なお，エミュレータを立ち上げていると重くて５分で終わらないので，アプリの動作確認は実機で行なうこととする。 以下から開始。 手順 ここでは新規PJ作成時にテストPJを同時生成するのではなく， 既存PJに対して，テストPJを後付けで新規作成する。 まず，テスト対象のプロジェクトを作成する。 ファイル＞新規＞Android Application Project で， 「HelloJUnit」という名称で新規PJを作成。 Create Act
『JUnit実践入門』写経・実践会 in 横浜 #2 を開催してきた #junitbook - Diary of absj31
『JUnit実践入門』写経・実践会 in 横浜 #2 - connpass 2013/01/12 『JUnit実践入門』写経・実践会 in 横浜 #2 #junitbook - Togetter 前回第1回に引き続きの書籍写経・実践会です。 『JUnit実践入門』写経・実践会 in 横浜 #1 - connpass 会場は横浜タネマキ。これまでには自身では何度も利用させて頂いていますが、今回は初めて会場貸切で開催してみました。 タネマキ 【コワーキング ＆ シェアオフィススペース】 横浜タネマキさん、設備等は以下のリンクにあるようなものが利用出来たりしますが、最近では無料ドリンクベンダー(無限かどうかは不明)が設置されており、好きなだけ飲む事が出来ます。これは素晴らしいですね〜。 施設の設備、外観とレイアウト - タネマキ 【コワーキング ＆ シェアオフィススペース】 今回は司会(ファシリ
junit-4.11.jar が単独で使えない - 日々常々
寂しがりだから 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のテストコードからはじめるGroovy #gadvent2012 - やさしいデスマーチ
本エントリーは、G* Advent Calendar 2012の24日目のエントリーです。前日は、@tetsurokitaharaさんのGroovyにProcessingを！でした。 何をネタに書こうかなと悩んだのですが、思うほどG*なネタは持っておらず、JUnitネタとなりました。実は、書籍「JUnit実践入門」でもGroovyを活用するトピックを入れる予定だったのですが、紙面の都合上、入れる事ができませんでした*1。そこで、少しだけですが、本エントリーで補足したいなと思います。 テストコードでGroovyを使う Groovyは、Javaと親和性の高いプログラミング言語です。上司を説得する場合は「GroovyはJavaの拡張ライブラリです（ｷﾘｯ」と言っても良いでしょう。本当は開発環境やビルドツールの設定などで一工夫しなければ利用できませんが、その辺は裏でしれっとやってしまえばOKです。
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 のテストメソッド名に日本語を使ったときの問題の解決法 (Java 7) - 全力で怠けたい
Java 7 にアップデートしたら日本語メソッド名が通らなくなった 現象 クラス全体をテスト実行すると動く 日本語メソッドを選択して実行すると動かない Java 6 の場合には問題なかったのに、7 にアップデートしたら上手いこと動きません。 しかし、6 に戻すとちゃんと動くので、7 が怪しい…と調べてたら、一応動くようになりました *1 「Java 6 の時には問題なかったのに 7 にアップデートしたら上手く動かなくなった！」そんな方にはこのエントリが役に立つかもしれません。 環境は以下のとおりです *2 Mac OSX 10.7.5 Java 1.7.0_07 Eclipse 3.7 JUnit 4.8.1 Quick JUnit 0.6.3 おすすめエントリ 〜まずはこちらから〜 Eclipse や JUnit と日本語メソッド名については良く知られている問題ですが、それだけに良エント
JUnit API探訪：アノテーション一覧 - Diary of absj31
アノテーションについてもひと通り把握しておきたい…と思ったのだが、思ったよりボリューム多めだったのでざっくり調査→行けるところから深堀把握の形と取ろうと思います。一覧の下、個別アノテーションについては自分なりの実践・写経・把握が完了したものから個別エントリに情報をシフト、切り分けて連携していく手法で随時更新して行こうかなと。あまり長引かせずに網羅したいところではあります。 現在、JUnit(4.10)で公開されているアノテーションは以下。 Class Hierarchy (JUnit API) アノテーション説明Blogエントリ 基本 @Test テストメソッドである事を知らせる Blog URL @Ignore テストを無視する Blog URL @RunWith テスト実行時のテストランナを記述 Blog URL テストの前処理・後処理共通化 @Before テストメソッドの前処理：メ
JUnit API探訪：Assertクラス／assertThatメソッド - Diary of absj31
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
JUnit/Javaテスティング界隈でBoostする為に有用なリンクを集めてみた - Diary of absj31
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
JUnitのテストメソッド名に日本語を使ったときの問題と対処 - 日々常々
メソッド名を日本語にする話 - 日々常々とかにも書いてるんですが、テストメソッド名に日本語を使うのはザラです。むしろ使わない理由がありません。こんなのですね。 import static org.hamcrest.CoreMatchers.is; import static org.junit.Assert.assertThat; import org.junit.Test; public class HogeTest { @Test public void ほげはほげのはず() throws Exception { assertThat("hoge", is("hoge")); } } 例が悪い？そこは気にしないでくださいませ。 さて、メソッド名に日本語を使った時に、一部IDEでは問題が起こることがあります。一部と言いつつ私はEclipserなのでEclipseの話です。 Eclipse
assertEqualsよりassertThatが好きなわけ - 日々常々
assertEqualsよりassertThatが好きなのは、Matcherもあるけど、引数の順番に悩まないからです。英語として云々なんてどうでもいい。。。。 2012-07-13 00:07:14 via YoruFukurou 元ネタ*1は「xUnitよりRSpecがいいとか言ってたひとは英文ぽいのがいいとか言ってたけどさー」みたいな感じでしたが、xUnitであるところのJUnitでも最近は assertThat なんてもんが入って英文ぽさを売りにすることもあったりなかったり。 ツイートでも言ってる通り、英文ぽさなんてどうでもいいと思ってます。可読性は大事だけど、読めるならそれ以上は要らない派。ならば決め手は何だ。書きやすさと、エラー時の表示です。 assertEqualsのばあい こんな感じに書きますね。短い。書く量が少ないのは良いです。でも１番目と２番目どっちがどっちだったか。 a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
