2010-03-09

GAE/J + Slim3 [はじめてのSlim3(2)]

前回の続きで「Creating a form」
  • war/twitter/index.jspのbodyタグ内を下記のように編集する
    <p>What are you doing?</p>
<form method="post" action="tweet">
<textarea name="content"></textarea><br />
<input type="submit" value="tweet"/>
</form>
  • 続いてこのフォームをsubmitした際の処理を行うTweetControllerを生成する。build.xmlのgen-controller-without-viewタスクで"/twitter/tweet"と入力すると以下のソースファイルが生成される("without-view"なのでjspは生成されない)
    • src/(ルートパッケージ)/controller/twitter/TweetController.java
    • test/(ルートパッケージ)/controller/twitter/TweetControllerTest
  • テストを実行してGreen(OK)となることを確認する
  • 次にテストクラス:TweetControllerTestを修正する。TweetControllerクラスは/twitter/tweet からリクエストを受けて/twitter/にリダイレクトすることになるので、それをテストするように修正する。
    run()テストメソッドの最後の２行を下記のように修正する。
    assertThat(tester.isRedirect(), is(true));
assertThat(tester.getDestinationPath(), is("/twitter/"));
  • ここからが「テスト駆動開発」の面白いところ。(^_^)/
    テストを実行してRed(NG)になることを確認する。
    これはまず対象クラスのテスト=仕様をコードで記述すること、そしてそのテストが失敗となることを確認することである。
    この時点でテストがOKとなってしまったら変だよネ。だから"正しく"失敗することを確認しなければならない。
  • では、次にテストが通るようにTweetControllerのreturn文を下記のように修正する。これでbasePath="/twitter"にリダイレクトされるようになる。
    return redirect(basePath);
  • これでテストが通るはず。テスト実行...よし！Green(OK)だ(^_^)v
このセクションは少し長いので、今日はここまで。

ついでに「テスト駆動」について。「テスト駆動」では基本的に下記手順で開発を進める。
  1. テストを書く
  2. テストを実行して結果(通常失敗(Red))を確認する
  3. コードを修正する
  4. テストを実行して成功(Green)することを確認する
  5. リファクタリングする
  6. テストを実行して成功(Green)することを確認する
実際にソフト開発作業で「テスト駆動」で行っているが、旧来の開発作業と比べて一番のメリットは、精神的に楽に開発できること。(^_^)
　旧来のやり方だとテストを始めるのは、一クラス全部コーディングしてから、または複数のクラスをコーディングしていきなり結合レベルのテストをしていた。
仕様通りに動作するかどうか分からない状態のまま(精神的にはものすごく不安な状態)黙々とコーディングし続け、いきなり単体テスト/結合テストを行う。こんなの動くわけないでしょ(-_-
それに精神的に不安で高ストレスの状態でコーディングしていたらミスを起こす可能性も高くなる。
　テスト駆動では、まずテスト(javaの場合はJUnit)を書く。"テスト"というよりは"仕様"をコードで表すと言った方がピッタリくるかな。このテストもいきなりたくさん書くのではなくて、テスト対象メソッド一つについてのテストを書く。(テスト要因が多い場合には、まず正常系、次に異常系という具合に進めていくと整理しやすい)
このように少しづつ進めることで一歩一歩確実に前に進めるので、精神的に非常に安定した状態で開発ができる。それと[テストを書く]-[テスト実施]-[コードを書く]-[テスト実施]-[リファクタリング]というサイクルを繰り返すことでリズムが出てきて、「ここまでOK」、「次...ここまでOK」という感じでスイスイ前に進み感覚になり、楽しくなる。
もう一つのメリットは「回帰テスト」が楽にできること。テストプログラムなので何十項目のテストも実行すれば一瞬で完了する。なので区切りのついた時やコミットする前などには必ずすべてのテストを実施してレベルダウン(デグレード)が無いことを確認するようにしている。

　ユニットテストの効用については２年位前に買ったお気に入りの本「アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣」の[５章 アジャイルなフィードバック]に色々説明されている。
この本、行き詰まった時などに読み返して[アジャイル]の初心にかえるようにしている。もう何回読んだかな？(結構影響受けたので、いずれこの本について書こうかな)
開発者なら「達人プログラマー―システム開発の職人から名匠への道」と並んで必読の本なので、まだ読んでない人はぜひ読んでくださいナ。
(↑Amazonの"商品プレビュー"を設定してみた、書籍名にマウスカーソルを合わせると本の画像がポップアップ表示されますよ)
ラベル: , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)