コントローラーとモデルのテスト方法って、多分、違うと思う。

　前のブログで、MVCモデルも、DBアクセスなんかでも、基本的には、コントロール部分と、実際の処理部分にわかれ、MVCの場合、Vがクライアント側、CとMがサーバー側で、Cがサーバー側コントローラー、Mがサーバー側処理部分といいました。

　で、テストの問題なのですが、コントローラーとモデルの部分のテストは違うと思うのです。
　なぜなら、処理内容が違うからです。

---

　じゃあ、コントローラーとモデルの処理内容は、どんなのかというと、こんなかんじ

■■　コントローラー
・データのチェック（あれば）
・モデル部分の呼び出し
　→条件によって呼び出し内容は変わることあり

■■　モデル部分
・データチェック
メインの処理に対する
　・事前処理（前処理）
　・主処理
　　→基本的なデータ操作と、下位の資源呼び出し
　・事後処理（後処理）

---

　つまり、データチェック以外の部分は、テストも違ってくるんじゃあ、ないでしょうか？

■■　コントローラーの場合のテスト

　結局、やっていることは、下位のモデル部分の呼び出しですから（もし、コントローラーで、これ以外の処理をやっているようだったら、それは、本当に、コントローラーなの？？）、チェックも、値を入れて、その値にしたがって、モデルのメソッドが呼び出されているかを確認することになります。

　ログは、モデルの呼び出し箇所に、受け取った値と、モデルの呼び出しメソッド名を入れて、
　テストは、値によって、正しい呼び出しメソッドが呼び出されているかのチェック
　　→境界値チェックとか
　エビデンスをとる場合は、その呼び出されたログ

　


■■　モデルの場合
　これを、モジュールからの呼び出ししか行わないで、テスト終了としてしまうと、モジュール内部で、やっている処理が本当に正しいかどうかわかんないことになります（たとえば、DBの更新処理で、更新をかけるテーブルに対して、正しくいっせいにロックしているかどうかなど）。

　なので、JUNITなどによる、ドライバからの呼び出しと、返り値チェックのほかに
　　→この呼び出し引数に対する、境界値チェックとかも、もちろんある

　ログを、データチェック、前処理、主処理、下位資源呼び出し部分、後処理の主要の所にいれ、
　→場合によっては、IF文の分岐のところも
　ログの表示内容は、その処理が終わったときに、その処理内で更新された値などを表示させ
　テストは、そのログが正しく取られているかどうかを確認する
　→ロックなどの場合は、ロックされている状態で、ほかのプログラムがアクセスをかけたとき、ログがどうなるか
　　（待ちになる、デッドロックするなど）を予想し、確認
　エビデンスは、ログになる
　→上記、ログを入れたところ１箇所ごとに対し、ログが正しく書き出されているかで１項目とする

となります。

　なので、コントローラーの場合は、どういう値のとき、何が呼び出されるか（表になってるとわかりやすい）、
モデルの部分の場合は、前処理、主処理、下位資源呼び出し部分、後処理など、処理のまとまりが（１，２，３などのように箇条書きで書いてあると便利）プログラム設計書に書いてあるとわかりやすいです。

---

　JavaDocの場合は、そのプログラムでどういう処理をするかは書いてありますが、上記のような、値と呼び出しメソッドの組み合わせ表や、処理手順と、その順番は書いてないことが多いのではないでしょうか？
　なので、こまってしまいます。

　でも、プログラムの仕様書を書く場合、普通、この内容をかく、フリーフォーマットの紙がついてきます。
　そこで、わかっているSEなら、その紙に、上記の内容を書いてあると思います。

　でも、わかってないSEやプロマネの場合は。。。問題です。

　この続きは、また、気が向いたときにでも。。。

O/Rマッピングも含めた、オブジェクト指向とのミスマッチの考え方

　昨日、インピーダンスミスマッチだけでなく、オブジェクト指向とのミスマッチは、いろんな資源と起こりえるのでないか？そして、その資源すべてを包括する考え方（もちろんO/Rマッピング含む）で、テスト仕様などを考えているというふうに書きました。
　昨日挙げなかった例で、付け足すと、実際での開発は、プロパティファイルから読み込んだ結果と、RDBから読み込んだ結果を合わせて、モデルとなるプログラムが欲しいなんていうこともあるわけです。そういうのでも、矛盾のない考え方が必要です。

---

　で、その考え方なのですが、業務アプリから、RDBやファイル、帳票、さまざまな資源にアクセスするわけなのですが、業務アプリから見た場合、それらの資源の違いを意識することなく、業務アプリに都合のいい格好で、取得したいわけです（この「業務アプリに都合のいい格好」っていうのが、（ちょっと古くなりますが）ひがやすをさんのブログに出てくる結果セット中心ということなのかなあと考えます）

　さて、「業務アプリに都合のいい格好」にするには、どうしたらよいか。
　実際の資源は、そういう形になっていないので、
　　　・それぞれの資源の部分の操作
　　　・それら複数の資源を呼び出し、コントロールし、矛盾のない格好で業務アプリにかえす
　という２つの部分があると考えます。
　普通のEJBだと、上記がエンティティbean、下記がセッションBeanに相当するんでしょうか？
　富士通Interstageだと、上記がCBM、下記がCBSに相当するということになります。。

---

　で、おやおやおやです。

　WEBシステムでみると、クライアント側がVIEWで、Viewにとって都合のいい格好にするため、サーバー側が、コントロールとモデル（この場合モデル＝資源の部分、上記で、コントロールは下記」
　つまり、MVCとは、サーバーとクライアント間の上記の構造で、DBなどの資源アクセスは、MVCからのモデル構造で呼ばれる上記の構造になっております。つまり、こんなかんじ。
　


　つーことで、この構造は階層構造になっていて、最上位の構造が、ユーザーインターフェースとなるView、一番下が、資源になります。なので、Webサービスを使うと、さらに、サービス提供側でも、このコントローラーとモデルの考え方が続き、さらなる階層構造を形成することになります。
　VIEWにおいてだけ、コントローラーがありません。本当にないのかというと、実は、コントローラーに相当する部分はあります。メニューです。でも、世間一般では、それを分けていないので、こう書いています。

---

　つーことで、気が向いたとき（次回とは限らない、もっと先かも）。この考えと、プログラム、テストの自動化、およびテストの考え方について書きます。