愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイッター
ヘルメットアタカ
F's Garage関連
このカテゴリ[Web系]の最新30件
モバツイッター、アクセス情報、iPhone対応、広告の話 えがちゃんが批判される理由は簡単、解決法も簡単 日記10/3:パソナテックイベント関連打ち合わせ Wire Free Gadgets Network 企業Webサイトには、そのあり様が現れる?! 動的URLのSEO効果について。 Webサービス事業者は、もっと広告をポジティブな関係にすべし。 はてブコメ一覧表示を一旦拒否して、また戻した ユーザーとしてのPerl,Ruby,PHP..... コミュニティの内輪性と寿命 ソニーイベント報告4日目/4:アプリキャスト ソニーイベント報告3日目/4:PetaMap モバツイ、セキュリティの取り組みについて。 ソニーイベント報告2日目/4:IPTVサービス branco ソニーイベント報告(1日目/4) :Life-X ネット系イベントが広げるべきスケーラビリティ そそそ、それ、カラメルでできるよっ! パソナテックイベントと、WebsigセマンティックWebイベント Joostがビジネス的にイケてないらしい。 Overtureのインタレストマッチの可能性 オープンソースと秘匿性のジレンマ CSSが普通に仕事で使えるようになった日 Google オープンソースのウェブブラウザ「Google Chrome」公開 カラメルのユーザー登録フォームの離脱率を調べてみた 何故、連載記事専用のRSSがないのか? 携帯向けツイッター(twitter)クライアントサービスのモバツイッター、携帯百景と連携 災害安否情報もモバツイをご利用ください、とか言っておくこと。 女性プロフィールがまとめる形で晒されてる件 何故、福山はvipperに人気があるのか。 月刊アスキー10月号斜め読み
[このカテゴリをもっと見る]
thatsPing
Powered by
Movable Type

May 06, 2008

ユニットテストって奴ですか?実は、そういうテストフレームワークをまだ使ったことがない。

テスト処理がフレームワーク化されてると良いなーと思ったのは、

マイカラメルのブクマ処理
スケーラブルWebサイトに書いてあった、flickrでメールのエラーケースを蓄積していくくだりの記述を読んだとき。
・CPANモジュールなどのインストールを見ていて。

あたりかな。マイカラメルのブックマーク機能は、pookmarkのコードを流用してるんだけど、Amazonや楽天を想定したブックマーク以外に、カラメルサイト内のブックマークだったり、アフィリエイトコードが含まれたURLの処理だったりと、いろいろ拡張してるんですが、これが思ったより結構複雑になって、最初は何かを修正したらアレが動かない、コレが動かない、なんてことが多少あった。

そうするとテストケースが複雑になって、何度もテストをするのが大変なので、ここはテストフレームワークを使って簡単に繰り返しテストができると楽ちんだし安全だとは思う。

これは「スケーラブルWebサイト」に書いてあったflickrでのメール処理のトラブル対処でも同じ事をが言える。

また、ビジネスロジックを担うクラスが、viewとは違う世界に存在する場合に切り離してテストしたいというのは自然なことだから、そういうケースに限られるのかな。


ローカルな開発でロジックレベルのテストってのは、「F's Garage:どのレベルのフレームワークが一番良いのか。」ではあってもなくても良いってのを書いた。

フレームワークを覚えるのは、その利便性よりも遙かに面倒くさいというのはあると最近思うようになってきたのでぶっちゃけてしまうが、テスト処理なんて必要だったら自分で書けばいいじゃんと思っている。

多分、僕がテストフレームワークを全然覚える気が起きないのは必要としていないからだと思う。

必要とした時に便利なテストフレームワークがあるから使ってみるのは、大変良いことであるが、別に過去に良いテストフレームワークがなかったからと言って、テストをしなくてよかったわけじゃない。

Java ServletでMVCアーキテクチャというものに触れたときに、まず最初にやったのはデザインを組み込む前に、データロジックのテストをしましょう、ということだった。

Modelのコードを、コマンドラインのプログラムから実行することができるのは良いなぁと思ったものだ。

OOPを勉強して最初に、いわゆるO/Rマッパーを自作したんですね。あの頃は、SQL文なるセマンティックな文法を手書きで書いてテストするのが嫌だったから、その部分は自動化したかった。(それはHibernateも多分、存在してなかったころのJava固有の不便があったからで、PHPなどではSQLは自分で書いた方が早いと思ってる)

だから、いわゆるCRUDのコードを簡単に呼び出せたらうれしいじゃないですか、と言うことで、DBアクセスのフレームワークを作ったんですね。

ただし、JavaBeansはecliseを使ってたものの結局は手打ちだし、where句以降はメソッドの引数と連動して手打ちだったし、1:Nの関係性などもあるし、フレームワークに連動するひな形のコードを用意して、そいつをカスタマイズするというアプローチだった。

確か開発が一ヶ月ぐらいしか時間がなくて、各機能パート毎でDBアクセスをまかなうロジックを3日ずつで作る人と、できあがったロジックを使って画面制御を作る人とで分業しましょう、みたいなスケジュールだった。しかも、後者の仕事は新たに人を採用するというリスキーな状況。

だからロジックを作る人のクオリティの担保は重要だったし、画面を使うことなくテストが必要だったので、コマンドラインのjavaプログラムでテストコードを書いてもらった。ダミーデータをinsertして、selectして同じデータになることを確認して、変更反映確認して、最後にデータ削除してOK?みたいなシナリオで。

そもそもデザイン工程が混乱していて、画面のHTMLが上がってくるのが遅れていたから、ロジック部分だけ先に開発しましょう、というのが理由だったと思う。


ただ、そうするとテストプログラムにカラム名の即値が書かれてしまうのでDBの設計変更が起きるたびにテストプログラムを書き換えなきゃいけない。特に数値型の変更なんかあった日にゃ、型違いのエラーになってしまうので、結構面倒くさい。

最初だけ作ってたけど、画面ができてからは使わなくなってた。

そんなところが僕の記憶にあって、テストケースを必要とするのは、入力値によって挙動が変わるケースが多数ある場合に、機能追加や修正後に互換性チェックを行う時に限られるのかなと思っています。

テストケースのメンテナンスが面倒であまりやってないとかってのは、どんなフレームワークを使ってもあるんじゃないかと思うんですがどうなんでしょ。

ということでユニットテスト自体が、イマイチ、ピンと来ないんですよね。


みなさんはWEB開発でユニットテストってやってますか?
どんなときに、あぁこれがあって良かった、と思いましたか?

■同じカテゴリ[Web系]のエントリー
>>前の記事 SELECT * fromについての話
<<次の記事 検索「ツイッター」、でモバツイッターが一切出てこない
■このblogの書き込み最新3件
GoogleDan モバツイッター、アクセス情報、iPhone対応、広告の話 えがちゃんが批判される理由は簡単、解決法も簡単
この記事への提案、提言一覧
この記事への提案、提言









あなたの情報を保存しますか?