株式会社ジェニシス 技術開発事業部の遠藤 太志郎です。
この度、我々ジェニシス技開では技術系の記事をメインにしたブログを開設し、
我々の持つ技術情報を全世界に発信していく試みを始めることになりました。
第一弾は私、遠藤が「テスト自動化シリーズ」と題しまして、しばらく連載させて頂こうと思います。
微力ではありますが、これを読まれた読者の方のお力になれれば幸いです。
では、本題に入ります。
「テスト自動化シリーズ」の最初は「JUnit4」です!!
……無論、世界一有名なテスト自動化ツールですので、皆さんご存じかと思います。
なので、今更JUnitなど語られても何の価値も無いと思う方もいらっしゃるでしょう。
しかし、今まで私が参加したプロジェクトを思い返してみると、
「何となくJUnitを使っている」だけで、JUnitに備わっている本来の機能を有効活用出来ていない人が非常に多かったです。
たまたま私の職場がそうだったというだけなら良いのですが、もしかしたらそこら中にそんな状態のプロジェクトが散在しているのかも、と思い今回、ブログ記事にしようと思いました。
では、私の言う「何となく使っている人」の例を挙げましょう。
まず、テスト対象のソースとして以下を定義します。
これに対し、JUnitのソースはこちら!!
こんなJUnitソースを書いている人がいたら、それは「何となく使っている人」の疑惑が非常に高いです。
何がダメかと言うと、「assertEquals」の部分です。
これはJUnit3の書き方でして、JUnit4に移行しても過去のソースが動くように互換性を持たせているだけで、本来JUnit4では非推奨としている書き方です。
JUnit4の書き方は以下です。
「assertThat」が登場しています。
ここがJUnit4のスタート地点です。
JUnit4を使うことで、エラー時に発生する文言が詳細になったり、Matcherインターフェースのような機能が使えるようになるなど、様々なメリットを得られます。
ソースの読み易さとしても、
「assert that actual_param is expected_param」と英語として成立しているのです。
英語圏の人ならより一層読みやすいわけです。
上述の高機能については次回以降の記事で記載しますが、
エラー時の文言の違いは以下に記載しておきます。
assertEqualsの文言
assertThatの文言
やはり「assertThat」の方が読みやすい文言かと思います。
今までJUnit3な書き方をしていた人は、これを機にぜひJUnit4に乗り換えて下さい。
次回は「Matcherインターフェース」をご紹介します。
Eclipseには『新規作成⇒JUnitテスト・ケース』というJUnitクラスの自動作成機能があります。
これを使うとテスト対象メソッドに対応したJUnitメソッドを自動出力してくれるので便利なのですが、この時、「import static org.junit.Assert.*;」が自動インポートされます。
これが自動作成直後の初期状態です。
しかし、この状態では「assertThat」の中で使っている「is」メソッドが使えません。
「is」メソッドを使うには、別途手動で、
「import static org.hamcrest.CoreMatchers.is;」
をインポートする手間が必要です。
しかし、「assertEquals」ならば、何もしなくても即使えます。
つまり、Eclipseの自動機能に頼ると自然とJUnit3の書き方に誘導されていくわけです。
これがJUnit4普及の障害になっているのではないでしょうか。
これをお読みになった皆様にはぜひ、この初期インポートの一手間を乗り越えて、JUnit4を活用して頂きたいです。
/** * 文字列を結合して返却します。 * * @param str1 * @param str2 * @return */ public String getConnectString(String str1,String str2) { return str1 + str2; }
これに対し、JUnitのソースはこちら!!
@Test public void testGetConnectString() { Sample001 sample001 = new Sample001(); String str1 = "株式会社ジェニシス"; String str2 = "技術開発事業部"; assertEquals("株式会社ジェニシス技術開発事業部", sample001.getConnectString(str1, str2)); }
こんなJUnitソースを書いている人がいたら、それは「何となく使っている人」の疑惑が非常に高いです。
何がダメかと言うと、「assertEquals」の部分です。
これはJUnit3の書き方でして、JUnit4に移行しても過去のソースが動くように互換性を持たせているだけで、本来JUnit4では非推奨としている書き方です。
JUnit4の書き方は以下です。
@Test public void testGetConnectString4() { Sample001 sample001 = new Sample001(); String str1 = "株式会社ジェニシス"; String str2 = "技術開発事業部"; assertThat(sample001.getConnectString(str1, str2), is("株式会社ジェニシス技術開発事業部")); }
「assertThat」が登場しています。
ここがJUnit4のスタート地点です。
JUnit4を使うことで、エラー時に発生する文言が詳細になったり、Matcherインターフェースのような機能が使えるようになるなど、様々なメリットを得られます。
ソースの読み易さとしても、
「assert that actual_param is expected_param」と英語として成立しているのです。
英語圏の人ならより一層読みやすいわけです。
上述の高機能については次回以降の記事で記載しますが、
エラー時の文言の違いは以下に記載しておきます。
assertEqualsの文言
assertThatの文言
やはり「assertThat」の方が読みやすい文言かと思います。
今までJUnit3な書き方をしていた人は、これを機にぜひJUnit4に乗り換えて下さい。
次回は「Matcherインターフェース」をご紹介します。
余談
プロジェクトの現場で未だJUnit3な書き方が多いのは、一重に「Eclipseの標準仕様」が原因であると私は考えています。Eclipseには『新規作成⇒JUnitテスト・ケース』というJUnitクラスの自動作成機能があります。
これを使うとテスト対象メソッドに対応したJUnitメソッドを自動出力してくれるので便利なのですが、この時、「import static org.junit.Assert.*;」が自動インポートされます。
これが自動作成直後の初期状態です。
しかし、この状態では「assertThat」の中で使っている「is」メソッドが使えません。
「is」メソッドを使うには、別途手動で、
「import static org.hamcrest.CoreMatchers.is;」
をインポートする手間が必要です。
しかし、「assertEquals」ならば、何もしなくても即使えます。
つまり、Eclipseの自動機能に頼ると自然とJUnit3の書き方に誘導されていくわけです。
これがJUnit4普及の障害になっているのではないでしょうか。
これをお読みになった皆様にはぜひ、この初期インポートの一手間を乗り越えて、JUnit4を活用して頂きたいです。
0 件のコメント:
コメントを投稿