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


初代モバツイ開発者
想創社再創業 / KMD博士課程
著書〜100万人から教わったウェブサービスの極意―「モバツイ」開発1268日の知恵と視点 [Kindle版]
お求めやすい夏休み特価!
このカテゴリ[Web系]の最新30件
本ブログは移転しました インターネットの遊び方を身につけよう ネットでの選挙活動と投票率 Web2.0がうまくいかなかったワケ WebにおけるMVCアーキテクチャの勃興と変遷 何故、PCはブラウザ、スマホはアプリなのか。 言っとくけどスマホは退化でもあるからな。 アイコン5000円とか、Web受注(発注)価格について。 残念なWeb論の骨子 HTMLってホントよく出来てるな。 「やまもといちろう×イケダハヤト対談イベント」のログを読んで ネットサービスの成功者は「とりあえず受託」という言葉使うのやめません? 全収集型RSSリーダーの終焉とソーシャル化するWeb 頑張ると報われるプログラマーの社会とは。 Perlが○○な話 アメリカ製品のすごさと不思議とワイヤフレーム どの人件費を考えても絶対にお得!利用規約ナイトがきっかけの本が出ます。 クラウドやモバイルを、もっと仕事で活用したいけど、どうやって会社を説得したら良いかわからない! スマホアプリらしいUXとは。 インターネットの変化に対して起こるモヤモヤすることを考え、整理する活動 Facebookは見なくてもいい情報が出てくるSNS 「あなたは影響力があるから、そんなことを言っちゃいけません」の問題点 Facebookに時間を取られすぎる対策 Paypalの本人確認がむかつく件 ネット系イベントがとても主催しやすくなった件 モバイルファーストが失敗なハズはないが、今はまだ時期尚早 やりがいはソートできない…非情なデータベース社会 2012年までのふりかえりと2013年へ ブラウザという平面の限界 ブログ記事の流通の難しさ
[このカテゴリをもっと見る]
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件
本ブログは移転しました インターネットの遊び方を身につけよう トトロが陽なら、『風立ちぬ』は陰?〜『風立ちぬ』の感想
この記事への提案、提言一覧
この記事への提案、提言









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