2008年7月13日日曜日

Grails Unit Testの中間まとめ

Domainに対して基本的なCreateやDelete、Copyなどが正常に動作するかどうかを、ControllerとかViewを作り始める前に、アプリケーションが肥大化する前に、最初から確認しておく(test-appで確認し続ける)ことは、データが中心であると考えた時に、とても重要なので、そこを集中してやってみようと思ってやり始めた。テストドリブンであり、ドメインドリブンを基本としたアジャイルな開発を目指したい。

ここまでの流れをまとめると、、、
1.この案件の中心的存在となるDomainを決めて、今まで聞き取った要件に合わせて、Domain同士がどう関連するかのイメージ図を、5回ぐらい書き直しながら作成した。
Domainの属性は、徐々にFixしていくものとして、最低限必要なものだけをピックアップした。
何が本当に必要なデータなのかを見極めるフェーズだ。

2.モデリングと照らし合わせて、業務フローを確認しながらまた数回書き直した。

3.grails create-appでアプリケーションを作成し、create-domain-classでDomainを作っていく。順番としては、一番重要なデータから見て、一番端にあるものからだ。

4.例えば、複数のDomainがHasMany、belongsToしている場合、各Domain単位でのTestを書いていると面倒なので、あとで分けることを想定して、DomainsTests.groovyと、そのテストデータをTestDataSet.groovyに作成する。(ともにtest/integrationの中)

5.DomainTests.groovyの中の先頭部分には、TestDatasの中のクラスを見に行けるように、下記を記述した。このClassLoaderを回さないと、testの中のクラスに辿り着けない模様。
class DomainsTests extends GroovyTestCase {
def gcl = new GroovyClassLoader()
def testDataClazz = gcl.parseClass(new File("test/integration/testDataSet.groovy")).newInstance()

void setUp(){
testDataClazz.testdataSetup()
}
}

6.TestDataSet.groovyには、、、
class TestDataSet {
def testdataSetup() {
def book = new Book()
book.name = "testBook"
}
}

7.と、しておけば、ここのSetupController.groovyとかで、このテストデータを使い回せる。

8.基本としてテストを書いたのは、
データ登録チェック、データ削除の際のHasMany、belongsToの違いによる挙動のチェック。

このようにやった結果、テストを書きながら、業務フローや画面遷移も想像しながら、Domain周りを固めていける。そして、後々細かい要件が出てくる際に、ここをベースにいけばよいので効き目があると思う。ただ、物事はシンプルさを貫き通さなければならない、ということを忘れないようにやらなければいけないと、もう一回心に誓うことも忘れないように。

9.あと、Controllerも作っておく。でも、Scaffoldに徹する。
class BookController {
def scaffold = Book
}

10.はじめてのrun-app
Scffoldなので微妙だけど、とりあえず動かして、データ登録の流れを確認。アプリケーションのイメージをふくらませる。

11.そして、Template-pluginをinstallしておく。generate-allすると、i18n用のタグをGSPに挟んでくれる。

12.そろそろ、generate-allで、controllerとviewを吐きだす。

また続き書きます。

0 件のコメント: