close
プログラミング クラウド Microsoft Azure 情報処理資格 基本情報技術者 IT基礎 応用情報技術者 開発・設計方法 オブジェクト指向 内定者・新人研修 プログラミング基礎 アルゴリズム コンピュータ数学 内定者研修 新人研修 ヒューマンスキル プロジェクトマネジメント プレゼンテーション リーダーシップ 組織マネジメント ネゴシエーション ロジカルシンキング Java UI/UX HTTP JavaScript基礎 情報処理資格 ネットワークスペシャリスト ネットワーク インターネットルーティング応用 IPアドレス データベース応用 SQL応用 パフォーマンスチューニング データベース設計 ER図 概念設計(データベース) 論理設計(データベース) IT資格 Linux基礎 OS・システム基盤 セキュリティ TCP/IP OSI参照モデル データベースセキュリティ ファイアウォール 標的型攻撃 SQLインジェクション ネットワーク基本設計 CCNA Cisco プロジェクトマネジメント資格 情報処理資格プロジェクトマネージャ 情報処理安全確保支援士 人事給与 財務会計 管理会計 簿記 生産管理 在庫管理 ERP バランススコアカード 情報処理資格 ITアーキテクト 情報処理資格 ITストラテジスト 情報処理資格 ITサービスマネジメント 情報処理資格 システム監査 PMBOK® PMP® プロジェクト計画 WBS リスクコントロール ITIL ITサービスマネジメント 要求定義 要件定義 見積手法 ビジネスインダストリ 業種・業界知識 業務知識 提案力 ソフトウェアテスト基礎 情報処理資格 データベーススペシャリスト ハードウェア基礎 外部設計(基本設計) 内部設計(詳細設計) データベース基礎 SQL基礎 RDBMS 物理設計(データベース) C++ Ruby MVC基礎 Webアプリケーション開発 JavaEE Javaプログラミング応用 フレームワーク MVC応用 Spring フレームワーク ソフトウェアテスト応用 テスト手法 JUnit スマートフォンアプリ開発 Androidアプリ開発 C# 基礎 C# 応用 負荷テスト Javaプログラミング基礎 ソフトウェアテスト コーチング メンタリング HTML/CSS サーバー構築 仮想化技術 KVS (NoSQL) アジャイル スクラム ファシリテーション C言語 ITパスポート JSTQB データサイエンス 単体テスト ユニットテスト キャリアアップ インターネットルーティング基礎 パケット解析 LAN構築 データベース データサイエンティスト トレンド 障害対応 インフラ監視 HTTP/2.0 コンピュータサイエンス VPN ネットワーク物理設計 データベース障害 JavaScript モダンJS (Modern JavaScript) 応用 MVS応用 バックアップ/リカバリ 分散処理 Hadoop Hive Python AI 深層学習(DeepLearning) CentOS Linux応用 Zabbix シェルスクリプト Infrastructure as Code Windowsサーバー基礎 内部設計 Docker DevOps Windowsサーバー応用 NginX chef Ainsible ロジカルライティング R テスト自動化 Jenkins Git 継続的インテグレーション (CI) バージョン管理 Vagrant 要求分析 Redmine 継続的インテグレーション(CI) 継続的デリバリー (CD) ヒューマンリソース管理 Web API マイクロサービス コミュニケーション 業務知識/業界知識 マーケティング 語学 AWS 法務 IoT ビジネスマナー OJT 業務効率化 表計算ソフト オフィスソフト コンプライアンス フロントエンド Subversion PHP 関数型プログラミング Laravel モダンJS (Modern JavaScript) 基礎 Android Studio 機械学習 iOSアプリ開発 ぷプログラミング React 次世代高度IT人材 共創 IPA Raspberry Pi Xamarin スクリプト言語 GoF CUI VBA 資格 ビジネス文書 jQuery 研修参加レポート マネジメント OSPF テーブル設計 アンガーマネジメント クリティカル・シンキング PDU 経営改善 Pマーク 問題解決技法 サイバー攻撃 エンジニア 参加してみた エンゲージメントマネジメント 労働関連法 新人育成 ネットワーク構築 情報セキュリティマネジメント デザインパターン リファクタリング マルチスレッドプログラミング ベンダーコントロール Modern JavaScript 冗長化 VLAN インフラエンジニア チームビルディング テストケース リーダブルコード セキュリティ入門 ネットワーク入門 Node.js npm gulp ビルドツール Python入門 冗長化入門 インフラ実機演習 プロジェクト管理 Active Directory ネットワーク管理 コンテナ 正規化理論 Haskell 品質管理 OpenStack シンギュラリティ DBA中級 プロトコル UX 基本設計 FinTech トラブルシューティング 並列処理 見える化 PMO ロジカルコミュニケーション Deep Learning インデックス設計 超上流工程 BGP Excel C-CENT Selenide プライベートクラウド アセンブラ コンピュータ基礎 工数見積 CCENT 法律知識 失敗から学ぶ プロジェクト失敗事例 PDCA プログラミング入門 非エンジニア向け 4Biz DNS セルフマネジメント 片付け術 サーバーダウン サーバー タイムマネジメント GO言語 プロダクトマネジメント プロダクトマネージャ LVS ロードバランサー 負荷分散 仮想通過 犯罪心理学 情報漏えい SEカレッジ導入事例 IT研修制度を聞いてみた CentOS7 開発環境構築 数字力 財務 IT人材 UI Machine Learning Go言語 (golang) データマイニング 統計学 新人教育 やり直し数学 RDB つながる工場 モチベーション WebSocket WebWorker HTML5 CSS3 Bootstrap 微分・積分 システム設計 決断力 LAMP環境 教育研修担当者向け ルーティング Linux入門 図解術 目標設定 試験対策 インタビュー技法 Vue.js ブロックチェーン DHCP 仕掛け学 BSC 財務諸表 自己分析 RIP スタティックルート バッファオーバーフロー DoS攻撃 システム開発 Wireshark パケットキャプチャ 管理職研修 部下育成 文章力 情報システム部門向け プロジェクトリーダー プロジェクトマネージャ 塗り絵 リスク管理 法改定 会社の仕組み Chainer AI人材 会話術 テスト技法 会社規模199名まで 会社規模49名まで 会社規模99名まで アプリ開発 サーバサイドJava 営業知識 Cloud 栄養学 基本コマンド ウォーターフォールモデル ヘルスケア 論理設計 ニューラルネットワーク ハンズオン UML 顧客ヒアリング マウスで学ぶ Apache EC2 Lightsail M5Stack DevSecOps プロジェクト成果 画像認識 チャットポット コマンド レビュー 基本用語 自動構築 LPIC-1 サーバーサイドJavascript キャリア形成 ワークライフバランス インバスケット テック用語 GitHub Windows エディタ 教養 令和時代 RESTful API 物理設計 会社規模300名以上 データモデリング サーバーサイドJava Webサーバー基礎 Webサーバー応用 Watson IBMWatson Learning Topics OS モバイル コンテスト トレーニング手法 アーキテクチャ 人材モデル インフラ CI/CD Infrastructure as a Code チーム開発 制度づくり Special_Intro AI市場分析 研修ロードマップ 仕事術 デジタルトランスフォーメーション 財務分析手法 情報整理 PowerPoint 新しい研修 オンライン研修 見どころ紹介 統計分析 ディープラーニング G検定 情報処理技術者試験 販売管理 C# テスト計画 Linuxサーバー WEBサーバ構築 http/2 Postfix イーサリアム プロジェクト・メンバ 正規化 パケット実験 作業分解 トラブル調査 ネットワーク設計 Windows server 2016 ネットワーク機器 DX 管理職 最新動向 ポストコロナ時代 IoTデバイス マイコンボード センサ サーバー仮想化 仮想ルータ WAN インターネットVPN 若手エンジニア ITプロジェクト 人事面談 DX人材育成 Java基礎 ZAP 脆弱性診断 NWサービス構築 イノベーション・マネジメント ネットワークセキュリティ ストレッチ Google Cloud Platform 不動産業界 テレワーク(WFH) ドリル GCP ( Google Cloud Platform ) システム業界 PMS テレワーク ビッグデータ NoSQL OWASP CentOS8 ネットワーク技術 データ分析 デザインシンキング 保険業界 会議リーダー システムエンジニア 段取り術 プロジェクト原論 文章書き換え術 ノーコード No Code MongoDB Redis Cassandra 運用管理 Windows10 仮想マシン リモートワーク 働き方 生産性 IPSec Office セキュリティマナー ソフトウェア・レビュー ライフハック

JUnit ではじめる単体テスト入門 研修コースに参加してみた


2020-11-25 更新

今回参加したコースは JUnit ではじめる単体テスト入門 です。

以前にレポートした 単体テストとテストケースの作り方 研修コースに参加してみた の拡張版コースで、品質計画から、テストの考え方、単体テスト(ユニットテスト)をおさらいして、 JUnit をじっくり 1 日かけて演習しました。

このレポートではそのうち、 JUnit を使った演習の部分を中心にレポートします。

なお、このコースはオンラインで開催されました。

コース情報

想定している受講者 Java 言語経験者
受講目標
  • JUnit および JUnit 周辺の拡張機能や各種フレームワークを学習する
  • テスト自動化の一歩を踏み出せるようにする

講師紹介

このコースで登壇されたのはクロノスのお馴染み 藤丸 卓也 さん です。

label藤丸さんが登壇した以前のコース

Git 入門 研修コース に参加してみた

今回のコースでは、オンライン研修でありながら、白紙の PowerPoint をホワイトボード代わりに、その場で図を描きながら説明するという工夫もされていて、わかりやすく理解できました。

白紙の PowerPoint をホワイトボード代わりに使う

講師紹介とあわせて、今日のコースでやることを紹介いただきました。

  • 今日の進め方
    • 前半は講習
    • 後半は演習。テストコードを書いていく
  • 単体テスト
    • 新入社員がはじめてやることが多い
    • 学ぶ機会も少ない
    • JUnit で自動テストしてみよう
    • テストケースや回数は感覚的になりがち

品質計画

前出の 単体テストとテストケースの作り方 研修コースに参加してみた と重複する部分は割愛し、新しく解説いただいたところを紹介します。

ポイントは単体テストは機能要件のテストであること。

  • 設計 -> 実装の前にテストケースを書こう(テスト設計)
  • それをレビューしてもらおう(抜け漏れなどが防げる)
    • 設計書のバグもチェックできる
  • レビューが通れば実装開始

単体テスト

  • 現場では「単テ」「UT(ユーティ。Unit Test の略)」とも呼ばれる
  • スタブ ( Stub ) とモック ( Mock ) の違い
    • スタブは依存するモジュールからデータをもらいテスト
    • モックは依存するモジュールを呼んでいるかどうかをテスト

単体テストのやり方

  • ホワイトボックステストの C2
    • ホワイトボックステストはプログラムの構造がわかっている
    • C2 は条件網羅のテスト
      • すべての条件式をテストする
      • 条件式ごとの命令も 1 回はテストする
    • C0, C1 ではなく C2 が一番多い
  • ブラックボックステスト
    • 入出力でテストする。プログラムの中身は知らない
    • 同値分割
      • 有効な値、無効な値から代表値を決めてテスト
      • これではテスト不足
    • 境界値分析
      • 有効/無効の境界の値でテストする
  • デシジョンテーブル
    • 入力と出力の条件の組み合わせが多い場合、表のようなもので現す
    • ex. 駐車場料金のディスカウント
      • 3000 円以上のお買い物で 1 時間無料
      • 5000 円以上のお買い物で 2 時間無料
      • :
      • 映画なら 3 時間無料
  • エラー推測
    • 異常系のテスト不足を補う
    • エラーが発生しそうなデータパターンでテストする
      • int であれば最大値、小数点など
      • string なら空文字、スペース、 null など
      • date なら閏年、存在しない日付・時刻
  • テストケースのチェックシート
    • 上記のようなものを含め、予めテストしたい項目を共有しておくと抜け漏れがなくなる

JUnit とは

ということで、いよいよ JUnit です。

まずは JUnit について紹介いただきました。

  • JUnit
    • Java で動作するテスト自動化フレームワーク
  • JUnit 5 を使います
    • 従来 JUnit 4 を使っていたが IDE で警告がでるため、切り替え
  • 単体テスト自動化だけじゃなく、拡張機能を使うと、結合テストまでカバーできる
    • Selenium で結合テストまで出来る
  • 自動テストとは
    • 開発したものが意図通りに動く
    • 処理を実行して、テスト結果の検証をプログラム(テストコード)で行う
    • ヒトが介さない
  • 自動テストのメリット
    • 何度でもスグに実行できる
    • 変更に強くなる
      • テストしやすい = 疎結合
    • 故障に強くなる
    • 仕様を永続化できる
      • テストコードが仕様
    • 属人性が排除できる

JUnit テストケース作成

ここから演習です。

演習は、仮想デスクトップにログインして、 Eclipse IDE から、用意されている演習サンプルを開いて行います。サンプルは、 Gradle を使ってビルドしています。

  • test コードと product コードが分かれたディレクトリ構成
    • 別に resource (画像やファイル) のディレクトリが分かれている
  • 対象プログラムの仕様
codeLogin.java ( product コード)
package secollege.junit.example;

public class Login {
	boolean authenticate(String userId, String password) {
    // 本来ならDB参照する
		if ("user01".equals(userId) && "passw0rd".equals(password)) {
			return true;
		}
		return false;
	}
}

1. テストクラスの作成

  • テスト対象のクラスから GUI でテストクラスを作成できる
  • テストクラスの名前は ‘テスト対象クラスの名前’ + ‘Test’ eg. LoginTest
  • 自動でスケルトンができる
    package secollege.junit.example;
    
    import static org.junit.jupiter.api.Assertions.*;
    
    class LoginTest {
    
    	@Test
    	void test() {
        fail("Not yet implemented");
    	}
    }
  • @Test というアノテーションが無いと、テストとして認識されない

2. テストケース (テストメソッド) を作成

  • 一般的にテストケース 1 つにテストメソッド 1 つ
  • 今回は クラス に対して、テストクラス
  • Eclipse などを使っていると、自動補完機能があるので、それを利用
    • Windows / Eclipse の場合、 Ctrl + space キーで表示
class LoginTest {

	@Test
	void testName() throws Exception {

	}
}

3. テストコードを書く

メソッド名に日本語が使えるので、日本語で書いておくとわかりやすいでしょう。

class LoginTest {

	@Test
	void 有効なユーザーの場合認証成功() throws Exception {

	}

	@Test
	void 無効なユーザーの場合認証失敗() throws Exception {

	}
  • カテゴリ ( given / when / then ) に分けて書くとよい
    • 検証コードを書くときにはアサーションを使う
  • 変数名に expected (期待値) や actual (実行結果) などわかりやすい命名ルールをつけよう
class LoginTest {

	@Test
	void 有効なユーザーの場合認証成功() throws Exception {
		// given: 検証するデータと期待値を書く
		String userId = "user01";
		String password = "passw0rd";
		boolean expected = true;

		// when: テスト対象の実行コードを書く
		boolean actual = new Login().authenticate(userId, password);

		// then: 検証コード
		assertEquals(expected, actual); // アサーション
	}
}

実は 1 行でも書けますが、 ↑ のように書いておくと、わかりやすいとのこと。 ちなみに 1 行で書いた例を紹介いただきました。

		assertEquals(true, new Login().authenticate("user01", "passw0rd"));

4. テスト実行

  • GUI から実行してみます (ショートカットでも OK )
  • Failure Trace に何もなければエラーなし

    • テストメソッドが日本語だと何のテストをしたのかわかりやすい
  • エラーがあった場合
    • 成功するメソッドの userId を変えてみる

JUnit の拡張を使ってみよう

  • 例外
  • パラメータ化テスト
  • 構造化テスト

JUnit の拡張プラグインを入れると、いろいろ便利に使えます。

今回はこの 3 つを使ってみます。

例外処理

対象のプログラムに仕様追加をします。

codeテスト対象プログラム
package secollege.junit.example;

public class Login {

	boolean authenticate(String userId, String password) {
		// ユーザIDの入力値チェック
		if (userId == null) {
			throw new IllegalStateException("ユーザID未設定");
		}

		if ("koizuss".equals(userId) && "passw0rd".equals(password)) {
			return true;
		}
		return false;
	}

}
  • assertThrows アサーションが JUnit 5 から使えるようになった
    • assertThrows(例外の型, テスト対象の実行コード)
      • 例外の型に注意。今回は IllegalStateException.class class まで書く
      • 第 2 引数の実行コードはラムダ式 (無名関数) で書く () -> new Login()
  • 実行すると例外が発生するので、 when と then が一緒になる
class LoginTest {
    // 中略

	@Test
	void ユーザIDが未設定の場合IllegalStateException発生() throws Exception {
		// given
		String userId = null;
		String password = "passw0rd";

		// when-then
		assertThrows(IllegalStateException.class, () -> new Login().authenticate(userId, password));
	}
}

実行してみます。

パラメータ化テスト

  • 例えば、文字入力ボックスがあったとして、 null など空文字、大文字小文字など様々な値が入る
    • いちいちそれをメソッドに書くときりがない
  • この入力値をパラメータ化することで、 1 つのメソッドで実行できる

対象のプログラムに仕様追加をします。

codeテスト対象プログラム
package secollege.junit.example;

public class Login {

	boolean authenticate(String userId, String password) {
		if (userId == null || userId.length() == 0 || " ".equals(userId) || " ".equals(userId)) {
			throw new IllegalStateException("ユーザーID未設定");
		}

		// 中略
  }
}
  • @ParameterizedTest というアサーションを使う
  • つづいて、 @ValueSource という引数を定義
    • ただし null は検証できない -> @MethodSource などを使う
class LoginTest {
    // 中略

    @ParameterizedTest
	@ValueSource(strings = { "", " ", " " })
	void ユーザーIDが空文字またはスペースの場合IllegalStateException(String value) throws Exception {
		// given
		String userId = value;
		String password = "passw0rd";

		// when-then
		assertThrows(IllegalStateException.class, () -> new Login().authenticate(userId, password));
	}
}

実行してみます。

構造化テスト

  • テストクラスをネスト (入れ子、構造化)できる
    • クラスの中にクラス
  • このあと紹介する DBUnit などで使う
    • 例えば、初期化の処理が違ったりする場合
  • テスト対象のプログラムは変更なし
  • テストクラスを構造化する
    • 認証を行うクラス
    • 入力値チェックを行うクラス
class LoginTest {
	@Nested
	class 認証 {
		void 有効なユーザーの場合認証成功() throws Exception {
			// 処理
		}

		void 無効なユーザーの場合認証失敗() throws Exception {
			// 処理
		}
	}

	@Nested
	class 入力値チェック {

		@ParameterizedTest
		@ValueSource(strings = { "", " ", " " })
		void ユーザーIDが空文字またはスペースの場合IllegalStateException(String value) throws Exception {
			// 処理
		}
	}
}

実行してみます。

ネストをどこまで OK にするかは、単体テストの粒度にも関わりそうですね。

そのほか便利な拡張機能や外部ツール

よく使われる拡張を 3 つ使ってみましたが、それ以外にも便利なものを紹介いただきました。

DBUnit を使ってみよう

  • 実際には JUnit 単体では使わず、基本は拡張ライブラリを入れて使う
  • DBUnit はデータベースの操作(ex. CRUD )を設定できる
    • ローカルで開発していると、開発者ごとにデータベースに入っているデータが違う
    • 結果が変わってしまうので、ツラい
  • 投入データには XML / CSV / Excel を使える
    • 今回は XML を使う

テスト仕様は ↓ です。

  • 対象プログラム
    • Dao: DB操作を行うクラス
    • Dto: 操作して得られた結果を保持するクラス
  • データベースの状態
    +-----------------------+
    | Tables_in_fruits_shop |
    +-----------------------+
    | fruits                |
    +-----------------------+
  • 投入するデータ
    <?xml version="1.0" encoding="UTF-8"?>
    <dataset>
        <fruits id="1" name="Apple" price="100" />
        <fruits id="2" name="Banana" price="200" />
        <fruits id="3" name="Cherry" price="300" />
    </dataset>

もちろん処理に合わせて、投入データを変えられます。

codeテストクラス

長いので、かなり省略して書きます

package secollege.dbunit.example.dao;

import static org.junit.jupiter.api.Assertions.assertEquals;
// 中略
import org.dbunit.Assertion;
// 中略
import secollege.dbunit.example.dto.FruitsDto;

class FruitsDaoTest {

	private static final String DB_SCHEMA = "fruits_shop";
	// (中略)

    @BeforeAll
    static void 全体の前処理() throws Exception {
    	// DB接続情報の取得など
    }

    @AfterAll
    static void 全体の後処理() throws Exception {
    	// リソースの破棄
    }

    @Nested
    class SELECTの検証 {

    	@BeforeEach
    	void 前処理() throws Exception {
    		// XMLに定義している情報をデータセットとして取得して、既存データを削除 -> 登録
    	}

    	/**
         * findAllメソッドのテスト
         * @throws Exception
         */
    	@Test
        public void Fruitsテーブルからデータを全件取得する() throws Exception {
            // データの全件取得や取得件数の検証
        }
    }

    @Nested
    class INSERTの検証 {

    	@BeforeEach
    	void 前処理() throws Exception {
    		// XMLに定義している情報をデータセットとして取得して、既存データを削除 -> 登録
    	}

    	/**
         * createメソッドのテスト
         * @throws Exception
         */
    	@Test
        public void Fruitsテーブルにデータを登録する() throws Exception {
    		// データセットを取得 -> テーブル定義を取得 -> データ登録 -> 取得

            // データの検証
            Assertion.assertEquals(expectedTable, actualTable);
        }

    }

}

投入するデータを追加して実行しみましょう。

<?xml version="1.0" encoding="UTF-8"?>
<dataset>
    <fruits id="1" name="Apple" price="100" />
    <fruits id="2" name="Banana" price="200" />
    <fruits id="3" name="Cherry" price="300" />
    <fruits id="3" name="Dragon Fruits" price="400" />
</dataset>

実行してみます。

ちなみに、ローカルのデータが変わってしまうのがツラい場合は、バックアップの処理を書いたり、seed の処理を書くとよいでしょう、とのことでした。

Mockito (モキート) を使ってみよう

  • スタブとモックの違いで説明したように、依存するモジュールが出来てない場合などに使う
  • 先の Dao クラスが行っていた処理をモック化してみましょう
  • Mockito というライブラリを使います
  • 対象プログラム
    • 先程の Login
    • ただし、依存する userDao クラスは完成していない
package secollege.junit.example;

import secollege.junit.example.dao.UserDao;

public class Login {

	UserDao userDao = UserDao.getInstace();

	boolean authenticate(String userId, String password) {
		// 中略
		// ここが今回追加したところ。DBに接続して、IDとパスワードを取得する
		if (userDao.getUser(userId, password) != null) {
			return true;
		}

		return false;
	}
}

では、モック化してみましょう

  • user.Dao をモック化
  • モックが返すデータを定義
  • user.Dao の getUser メソッドをモック化
// 中略
import org.mockito.Mockito;
// 中略

class LoginTest {

	@Nested
	class 認証 {

		@Test
		void 有効なユーザーの場合認証成功() throws Exception {
			// given

			// テスト対象クラスのインスタンス化
			Login login = new Login();

			// Dao オブジェクトをモック化
			login.userDao = Mockito.mock(UserDao.class);

			// モックが返すユーザーデータを定義
			User user = new User();
			user.id = userId;
			user.password = password;

			// userDao.getUser をモック化
			Mockito.when(login.userDao.getUser(userId, password)).thenReturn(user);

			// when
			boolean actual = login.authenticate(userId, password);

			// then
			assertEquals(expected, actual);
		}

		@Test
		void 無効なユーザーの場合認証失敗() throws Exception {
			// 中略
		}
	}

	// 中略
}

実行してみます。

Selenium を使ってみよう

  • 結合テストのときに使う
  • 具体的にはブラウザの操作をプログラムで書ける
    • Selenium はブラウザの操作ライブラリ
    • Selenide はブラウザの操作テストライブラリ
      • エラーのスクショを自動で撮ったりできる
  • 今回のテスト

今回はブラウザで直接テストするので、対象プログラムはありません。早速、テストクラスを見てみましょう。

// 中略
// なお、 DBUnit なども同じだが、 Gradle などのビルドツールの設定ファイルにも書く
import org.openqa.selenium.By;

import com.codeborne.selenide.Condition;
// 中略
// chrome を使うときはドライバが必要。Firefox は必要なし
import com.codeborne.selenide.WebDriverRunner;

class GoogleSearchTest {

	@BeforeAll
	static void setup() {
		// WebDriverの設定
        Configuration.browser = WebDriverRunner.CHROME;
        System.setProperty("webdriver.chrome.driver", "C:\\chromedriver.exe");
	}

	@Test
	void Googleトップページで検索() throws Exception {
		// Googleトップページを表示
		Selenide.open("https://www.google.com");

		// 検索ボックスの要素取得
		// Selenide.$ : 画面上の要素取得(jQueryのようにセレクタ指定ができる)
		SelenideElement element = Selenide.$(By.name("q"));

		// 検索ボックスに“JUnit"と入力して検索
		element.val("JUnit").pressEnter();

		// 検索結果の取得
		// Selenide.$$ : 複数要素を配列で取得
		ElementsCollection searchResults = Selenide.$$(".LC20lb");

		// 検索結果の検証
		searchResults.get(0).shouldHave(Condition.text("JUnit - About"));
	}

}

実行してみましょう!

CI / CD

今回は触れられなかったんですが、自動テストをフックに DX ( Developer Experience 開発者体験) 向上にも繋がります。

  1. GitHub などリポジトリサーバからプッシュ
  2. Jenkins など CI ツールが以下を実行
    1. 自動でビルドツールが走る
    2. 自動でテスト実行
    3. 結果を Redmine などバグトラッカーに登録

テスト自動化をやるのかやらないのか

テスト自動化は便利だけど、初期コストがかかるので、その損益分岐を考えることが重要、というお話です。

  • 自動テストを書く工数がかかる
  • テストをメンテナンスする工数がかかる
  • 品質が必ず上がる訳ではない

開発期間が 3 ヶ月を超える、開発規模が大きいなどの場合は、初期コストを回収しやすくなります。

このため、

  • やっても無理をしない(初期コストを肥大化させない)
  • ただ、やるなら早めにやる
    • あとからやるのは大変。。テストコードを書いているうちにプロダクトコードは拡大する
  • やるなら、テストコードを先に書こう

このような心がけが必要です。

いまの DX (デジタル・トランスフォーメーション) のような開発には、アジャイル開発はほぼ必須なので、やってみましょう、とのことでした。

まとめ

このコースでは、 JUnit による単体テストについて、実践をまじえて学びました。

JUnit の使い方の基礎だけでなく、テストメソッドの名前や、メソッドの内部の整理方法、アンチパターンなど、テストケースを書くうえでの心得まで解説されました。また、演習の例題においても、よく使われる拡張や外部ツールとして DBUnit, Mockito, Selenium などを解説するなど、実践を意識して解説されました。

ここでレポートしたほかにも、品質基準や品質計画、あるいはどのようにテストすべきなのかなど、テストと品質に関して全般が語られました。

JUnit でテストを書いたことがない方や、何をどうテストしたらいいか自信がない方など、テストに悩んでいる方におすすめのコースです。

 


SEカレッジについて

午前免除 FAQ

タグ一覧