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 件のコメント:
コメントを投稿