grails build-test-dataプラグインを使用してテストデータを準備

詳細
なに?!データのテストに特化したプラグインもありますか?では、この任務は簡単すぎるはずです.そうですね.単一のテストから言えば、テストデータの準備は確かに簡単ですが、多くのテスト例を持っていると、そんなに簡単ではありません.前述したように、ここで指すテストデータはGrailsアプリケーションの分野クラスデータを指す.
Grailsアプリケーションにユニットテストを書いたことがある場合は、テスト前にレルムクラスのデータを初期化する手順に慣れていないはずです.最初は、Grailsが本当によかったと思うかもしれませんが、以前Spring+Hibernateを直接使ったときよりずっと爽やかで、特にユニットテストは、こんなに便利な方法と配置を提供しています.今回は必ずユニットテストを書き続けなければなりません.ゆっくりと、新鮮さが過ぎて、残りは繰り返し作業(特に分野類のテストデータの準備)にうんざりしていますが、この時はまだあなたが狂っている時ではありません.そして、あなたのアプリケーションに提供される安全防御線をテストするために、あなたはまだ受け入れることができます.結局、生活は以前よりずっとよくなった.その後、ビジネスのニーズにより、レルムクラスに新たな制約が追加されました.数行のプログラムを少し変更してテスト例を書き終わった後、自信満々に「grails test-app」を入力した後、変更されていない多くのテストが失敗しました.ああ、どうしたんですか.
このとき、さっきレルムクラスに制約を追加しましたが、レルムクラスは保存時に制約を満たす必要があります.前のテストはテストデータの準備に関連している可能性が高いようですが...原因は見つかりましたが、失敗したテストは合格させなければなりません.仕方がありません.袖を引っ張って、前の100のテスト例の中でこの制約が属する分野類に関連するテストのデータ準備部分を30分かけて見てみましょう.
もしかすると、setupもあるのではないでしょうか.初期化作業はそこに置けばいいのではないでしょうか.そうです.これは確かに一部の役割を果たすことができますが、各テストが同じテストデータを使用したいとは限りません.また、このようなデータの準備と衝突する修正(修正制約など)が発生するたびに、このような修正は避けられません.特に、テストの重点が分野クラス自体ではない場合、このような修正は受け入れにくいです.
以上、複雑な関係を持つ領域クラスのデータ初期化については言及していませんが...他に変更がなくても、データ準備については煩わしい作業です.
これらはbuild-test-dataプラグインが登場した理由で、先ごろ1.0版がリリースされました.
build-test-dataに慣れていない場合は、すべてのGrails分野クラスにbuild()メソッドを追加するように簡単にまとめることができます.このメソッドを呼び出すと、レルムオブジェクトのインスタンスが自動的に構築され、保存され、すべてのレルムコンストレイントに従います.また、明示的に設定したい値を上書きすることもできます.コンストレイントのみを満たす巨大なオブジェクト図ではなく、テスト方法に実際に関連する値を指定する必要があるため、テストをより明確にし、より堅牢にします.
次のコードはTed Naleidのスライドから抜粋され、このプラグインの基本的な使用方法を説明しています.

	// 
	class Author {
	    String name
	    static hasMany = [books: Book]
	}
	class Book {
	    String title
	    static belongsTo = [author: Author]
	}
	 
	// 
	def book = Book.build()
	assertNotNull book.author
	assertNotNull book.title
	 
	// title
	def book = Book.build(title:"Infinite Jest")
	 
	// author
	def book = Book.build(author:
	    Author.build(name: "Charlie Stross")
	)

build-test-dataプラグインに興味がある場合は、このwikiから詳細を知ることができます.また、この優れたスライドは、迅速に理解するのに役立ちます.