テストについて

Java T2

さすがにOSI参照モデルまで疑おうとすると範囲が広すぎてしまいますが、
(X)HTML、JavaScript、CSSに絡むテストケースはいわばクライアントの影響を
もろに受ける部分な訳で（Flexならなおのこと）、これを業務ロジックとかRDBMSとの連携の部分と
いっしょくたに取り扱おうとしても、そもそもがきれいに結びついてくれないと思います。

という訳で、プログラム自体をなるべく小分けにして、個別にテスト出来るようにすることでまずテストケースの組み合わせ爆発を防ぎ、かつクライアント向けのコードとサーバ・サイドのコードと同じ視点で扱わなくても良いような設計にしてあげないといけないな、と。

(途中略)
それよりも、フレームワークという単語が指し示す「枠組み」としての側面を強調して、生産性というか作業効率に寄与するようなものを目指さないと、ですね。

http://d.hatena.ne.jp/itengineer/20080705#1215275149

まずはUTで機能単位でテストしておき、ITで大枠からのテストを施すのが王道じゃないですかね。
言い方を変えればミクロ視点・マクロ視点になるわけです。

UTにおけるxUnitは本当に各機能・部品の振る舞いを確認するためのものです。
メリットはもちろん自動化されていて回帰性が高いことで、一番ミクロな単位での品質の確保です。
ミクロ視点なので各部品ごとの振る舞いは担保されますが、もっとマクロな視点でみたときの
挙動を担保はしてくれません。

よりマクロ視点ではITでの確認が有効だと思います。
しかしながらITの自動化は思ったほど進んでいないんじゃないかと想定しています。
（そんな中でもいま一番使われているのはSeleniumかなあと思ってますが。）
そのため、xUnitライクでITも記述できて回帰性を担保するのは
開発全体の効率化にはとても有効なんではないかと思います。

また、xUnitライクなITでマクロ視点でのテストを記述しておけば、
開発が進んで追加案件や保守時にも既存のベースラインとなる機能を
壊していないことを簡単に確認する手段となりうるんではないかなあと感じています。


UTだけでなくITも自動化できる、そういった機能まであわせて提供できるフレームワークを
うまいこと小さなコストで出来ないかなと試行錯誤してます。テスト支援系は優先度高めで考えてます。