nDiki : JUnit

新たなアノテーション・ベースのフレームワーク、<strong>JUnit</strong> 4 には TestNG の選り抜きの機能がいくつか含まれていますが、それによって TestNG が使われなくなることを意味するのでしょうか。この記事では、Andrew Glover がそれぞれのフレームワークの特徴を検討し、まだ TestNG にしか見当たらない高度な 3 つのテスト機能を明らかにします。 <strong>JUnit</strong> 4.0 は、長い間開発が中断された末、今年

http://www-06.ibm.com/jp/developerworks/java/library/j-cq08296/index.shtml?ca=drs-

<strong>JUnit</strong>は、Java&trade;;言語用のユニット・テスト・ライブラリーのデファクト標準です。<strong>JUnit</strong> 4は、このライブラリーにとって、過去約3年間で最初の重要リリースです。<strong>JUnit</strong> 4では、テストの識別に関してサブクラス化やリフレクション（reflection）、命名規則（naming convention）などに頼るのではなく、Java 5の注釈機能を利用しており、それによってテストが単純化されると言われています

http://www-06.ibm.com/jp/developerworks/java/051007/j_j-junit4.shtml

Happy path testは&quot;expected behavior&quot;-期待される動作 を検証する。 Happy path test自体はアンチパターンではないが、デベロッパがhappy path testを１つだけパスしてそれでおしまい、と思ってしまうところがアンチパターンとなる。例えば違ったメソッドでも同じアーギュメントで同じ値を返す場合もある。 偶然にパスする、と言うこともありうるのだ。 そのため、happy path testは少なくとも２

http://izu.shinzui.org/comments/start/2005-08-02/1

先日、Kent Beckのインタビュー記事 Developer Spotlight: Kent Beckを読んでいたら、以下のような記述に出会いました。 Erich Gamma and I are working on a new <strong>JUnit</strong> release that will mark its first significant architectural changes since <strong>JUnit</strong> was very young. むむっ、significant architectural changesとはどのようなものなのでしょうか。 興味を持ってsfの中を探してみると...Version4というブランチがありました。もう開発が始まっ

http://d.hatena.ne.jp/t-wada/20050601#1117601161

上述のようにテストを書いていると、ふと、「setPriceCodeでMovieクラスに定義してある定数以外の値を入れたらどうなるのだろうか」、と思いました。当初の設計（コーディング）では、setPriceCodeに定数以外の値を入れたことを想定していません。テストケースを書いていると、このように想定していなかった事態を思い付くことが多々あります。上述のMovieTesterではこの展開を記し

http://www.alles.or.jp/~torutk/oojava/maneuver/2000/6-3.html

いままで、我々の認識不足により、 d<strong>jUnit</strong>は、CPLライセンスで公開していましたが、 jcoverageのライセンスと矛盾するとの指摘をいただき、 d<strong>jUnit</strong>は、GPLライセンスであるべきと判断いたしました。 ご指摘いただいた方に感謝いたします。 他にも気がついたことがありましたら、指摘していただけると助かります。 d<strong>jUnit</strong>とは&nbsp;&nbsp;Λ d<strong>jUnit</strong>は、ユニットテストを安全かつ、低コスト

http://works.dgic.co.jp/djwiki/Viewpage.do?pid=@646A556E6974

ソフトウェア開発において、テストを行う際に、テストがきちんと行われているかどうか検証する必要があります。テストの検証を行わないと、テスト漏れによりバグが発見できず、システム運用時に思わぬ不具合を引き起こす可能性があります。 そこで、テストの検証を行う手段として、カバレッジがあります。カバレッジはコード中のテストにより実行されたコード、もしく

http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn02/eclipseplgn02_2.html

なんとなくテストコードはかけるようになった。 でも、公開（パブリック）メソッドだけでなく、 内部実装であるプライベートメソッドの方も直接テストしてみたい。 というわけでやってみよう。 ●プライベートメソッドをテストしたい ちまっとソースを書いてすかさずテストというサイクルをまわすには、 プライベートなメソッドもテストしたくなる。 というか、実際には

http://www.ki.rim.or.jp/~kuro/Java/JUnit/JUnit-04.html

<strong>JUnit</strong>を使うと、目的とする要求に合致しているというアサーション（assertions）を行うことでソフトウェアのコード・ユニットをテストできるようになりますが、こうしたアサーションは初歩的な操作用に限られています。この記事では、IBMのソフトウェア技術者のTony Morrisが<strong>JUnit</strong>用の<strong>JUnit</strong>X（Assertion Extensions for <strong>JUnit</strong>）を導入して、その隙間を埋めます。<strong>JUnit</strong>Xは、<strong>JUnit</strong>フレームワーク内

http://www-6.ibm.com/jp/developerworks/java/050318/j_j-unitx.html