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


モバツイの中の人
マインドスコープ(株)社長
人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイの2つのスマートフォン
アンドロイドアプリ!
アンドロイドアプリ モバツイtouch
全てのスマートフォンブラウザと、Nintendo3DSで! HTML5版Webアプリ「モバツイsmart」
本を書きました!
100万人から教わったウェブサービスの極意 ~「モバツイ」開発1268日の知恵と視点
Google Friend Connect
このカテゴリ[Web系]の最新30件
インターネットの可能性を信じて〜本を書きました。 ネットショップに20万円は高いという感覚は割と普通の感覚だと思う。 ソーシャルメディアの生かし方 インターネットは芸術だ ECサイトはGoolge検索エンジンのプラットフォームに乗ってることを自覚せよ Ubuntu 8.0.4でTwitter apiのSSL通信ができなくなった人向けのメモ インターネットを支える仮想共同体 twitterとfacebookのレイヤーは違う 文脈が共有できていないフロー型コミュニケーションの問題点 身も蓋もなくなるインターネット フェイスブックページっで起きるかなぁ?!って思ってること。 非公式RTじゃないとできないこと。公式RTが目指したもの。 ツイッターのつぶやき価値 ネットコミュニケーションは万人の手段ではない AWS東京リージョンとtwitter apiの関係 Facebookがインターネットになると困る デジタルネイティブではない30代のつぶやき ネチケットとアーキテクチャという法律のあいだに。 相撲の八百長問題に見られる、ITによるフローのストックという構図 Webエンジニアスキルの勘所 ツイッター面白いね WebSig一日学校で考えてたこと ソーシャルメディアについてのメモ User Streamの先にあるtwitter Web Creation Awardsにノミネートされました。 携帯Webのクッキー利用について調べてみたメモ【update】 twitterドラマと今後のツイッター デジハリの杉山学長賞をいただきました。 日経電子版を流行らせる一つの思いつき 商品の良さとリンクは、140文字で伝えなさい
[このカテゴリをもっと見る]
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件
インターネットの可能性を信じて〜本を書きました。 バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有
この記事への提案、提言一覧
この記事への提案、提言









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