テストテクニック

Android Studio で Junit を使いたいので、戦い続けて挫折して立ち返って立ち直った話

片桐　継（Tugu Katagiri） — Thu, 21 Aug 2014 16:49:00 GMT

最初、EclipseでJunit 4.11+Robolectricを使ってたんだけど、AndroidStudioに移植した時に、全部グリーン状態のソースを移植したのでテストコードは省いてたｗ

なので、機能追加のついでに、テストコードも移植しようと思ったんだけど、意外な展開が。

!!! JUnit version 3.8 or later expected:

java.lang.RuntimeException: Stub!
＜中略＞
Process finished with exit code -3

素直にRobolectricを依存ライブラリに追加して実行して、なにこれ？？？というわけで色々と調査。で、判ったことは

Android StudioでRobolectric使うならプラグインいれましょう
クラスパスはJunit＞SDKの順番でライブラリ参照しましょう

あふー、gradleをいじる羽目になりましたですよorz　書き直すのメンドイなー。

RobolectricスタッフのブログやGoogleGroupを見る限りだと、この辺りの問題はできたら解決したいなー的レベルらしくて、しばらくは手動でごにょごにょの世界のようです。まぁAndroid Studio自身がbetaの立場だもんなー、正式版になってからなんだろうなぁ（遠い目）

で、やってみたこと。

app/build.gradleにrobolectricの依存ライブラリ追加
ルートのbuild.gradleにrobolectricのプラグインのための依存ライブラリ追加
app/buid.gradleにrobolectircのプラグイン追加
ここで、いったんgladleをSync
ターミナルから、プロジェクトルートでgladle robolectric を実行し、必要なクラスがコンパイルされていることを確認
テストコードを書いて、ライブラリが追加出来ていることを確認
テストコードから生成されたクラスの出力先をクラスパスに追加
プロジェクトルートにある、.imlファイルの中にあるクラスファイルの読み込み順番を変更
gladlew androidTest を実行

さらっと書いたけど、２から５の間はgradleソースの読み込みだったので、簡単じゃなかったよorz 　gradleソースはpom.xmlよりも何をやっているのかソースで追える分、楽と言えば楽だし、親切と言えば親切なんだけどね。やっててよかったgroovy。

そして、何とかたどり着く9のフェーズ。ここで恐怖のハマりポイント、自クラスをクラスパスにうまく追加できない、をやらかしてしまった。いや、世界には、この方法で解決している人もいるので（成功例がMacOSXだったりするのがとてもとても気になるけれどもｗ）きっと、何かが悪いんだろう。

収穫はgradleソースが読めるようになった、ってことで、挫折orz

これに丸々二日ハマって、なんか疲れたんで、基本に立ち返ってみたんだ。

Android SDK　にテストフレームワークがあるのかな？

結論から言えば、ある、Junitがある。ただし、バージョンは3.8。便利なassertもアノテーションも全滅のオールドタイプさん。まぁ悪いバージョンじゃないんだ、基本機能はガッチリ揃ってるし、実績も高いしさ。まさかとは思うけど、Mavenリポジトリサイトで、Junit3.8のダウンロード数が廃れないのは、こいつのせいだったりしてねｗ　

Testing Fundamentals | Android Developers:
http://developer.android.com/tools/testing/testing_android.html

基本に立ち返って、もう一度、この記事を目皿にして読み直し、抜粋したポイントは

ディレクトリを作成する
テストしたいAndroidオブジェクトに対応したTestCaseを継承してテストコードを書く
Android Test を実行する

これだけ。じゃ、やってみようか、もちろん、最初はレッドのテストでね。

まず、ディレクトリ作成

デフォルト配色で、androidTest/javaフォルダが緑色になればOK。これは、テストクラスのあるパッケージディレクトリですよ、を指している色で、これが指定されていないと、後の作業がメンドクサイ、フォルダ見難いｗ

このフォルダの指定は、モジュールの.imlファイルに記述されているので、検索してフォルダ表記が無かったら、それを記述追加してリビルドすれば環境ができているはず。できるだけ、いじらないでいたいなら、テストクラスとして指定されている別のフォルダがすでにあれば、それを新規作成すると後も綺麗に続けられるので楽。テストクラスのパッケージフォルダ記述が無いなら、仕方ないから追加ね。

そして、テストクラスを新規作成。これはいつもの新規作成の手順でOK。

public class ApplicationTest extends ApplicationTestCase<Application> {
    public ApplicationTest() {
        super(Application.class);
    }

    public void testAssertion(){
        assertEquals(1,3);
    }
}

絶対レッドのテストｗ＜手抜きすぎｗ

今回はアクティビティやコンテンツのテストではないので、ApplicationTestCaseを継承したけど、テストしたいものによって継承するテストクラスが異なるので、細かい事は前記述のサイトのリンクから参照で。(そのうち、まとめるとは思うけどｗ)

クラスが書けたら、次は実行設定。私は、モジュール内のｘｘｘｘTestクラスのtestXXXXメソッドを総なめにした。細かくやりたい人はパッケージ事とかに分けると良いと思う。

Android SDKのJunitは実行環境を必要とするのでエミュレーターは起動しておき、立ち上がりを確認したら、テストを実行してエミュレーターに環境割り当てをすると、テストモジュールがエミュレーターにアップロードされて……

よっしあぁ！レッドすねぇぇくかもぉぉん♪

というわけで、立ち返ってからレッドになるまで、２時間だったというオチｗ

基本って大事だね！　痛感したわ。

JUnitのassertはどうして書くのが良いんだろうか？

片桐　継（Tugu Katagiri） — Wed, 23 Jul 2014 10:20:00 GMT

ちょっと、迷って困ってた。

JUnitのテストを書いてて、

とある整数型リストは、1,2,3,4 の四つの要素を持っているはず。
リストの要素の順番はどうでもいいが、要素の中身はこうであるはず。

ってのを、JUnitのassertで検証したい、となった時、書き方としては、

assertTrue(actItem.getRolled().containsAll(Arrays.asList(1, 2, 3, 4)));
assertThat(actItem.getRolled().containsAll(Arrays.asList(1, 2, 3, 4)), is(true));
assertThat(actItem.getRolled().toArray(new Integer[0])
　　　　　　　　, IsArrayContainingInAnyOrder.arrayContainingInAnyOrder(1, 2, 3, 4));

と、こんな風に、色々とあるんだけど、どれが判りやすいんだろうか、正しいんだろうか。

考えるネタとして、逆に、このassert文はこれをテストしたいんだな、と、assert文から読み下してみたらどうなるのかなぁと思って、やってみたの。

１２３４の値で構成されたリストを引数としたContainsAllメソッドの実行結果が、trueであることを確かめたい。
１２３４の値で構成されたリストを引数としたContainsAllメソッドの実行結果が、戻り値trueであることを確かめたい。
リストの構成要素を整数配列型にキャストした結果が、並び順関係なく１２３４の要素で構成されていることを確かめたい。

こうなった。なので、この場合、確かめたいことをassertしているのは、３ってことになる。

だって、テストしたいのはContailsAllメソッドじゃないし。リストの要素だし。

といいつつも、私は個人的な好みでシンプルな１が好き。何をassertしたいのか、コメントしとけば良いもん。＜我儘ｗ

でも、個人のお気楽開発ならこんな風に好きにして良いけど、チームでの開発であるなら、こういうの、きっと、どれにしときましょ？とすり合わせた方がいいね。

assertの書き方は、チーム内なり、プロジェクト内なりで、ある程度基準を作っておくと、ここで何を確認したかったのか、仕様の要点が何なのかが判りやすくなって、後から来た人にも、作って忘れちゃってる人にも、親切なテストコードになると思うの。よくある「好きにしていいよ」が一番よろしくないオチ。後で混乱したり、なんでこうなってるの？、これはなにをテストしてるの？が起きちゃうこと請け合い、つか、経験則ｗ

私、MVCでTDDやってます。

片桐　継（Tugu Katagiri） — Wed, 21 Dec 2011 06:08:00 GMT

はじめに

この記事はTDD Advent Calendar jp: 2011 : ATNDの参加記事です。

私で21日目に突入しました。20日目は、haru012さんの

Testing と私と苦い出来事

でした。体験談かぁー。私も炎（ｒｙ　ごほんごほん。

てな感じで、今までの記事では、TDDの色々がとてもお勉強になるお勧め記事がたくさんでしたが、私のはちょっとだけ業務アプリケーション開発の実作業に近づいた内容かもしれません。まぁ、実際の所、私はこんな風に思ったよ、というのが正しいのですけれども。

MVCとTDD、それぞれの利点

MVC（Model-View-Controller）と呼ばれるデザインパターンが流行ってます。実際、私も使ってます。MVCって何？って方は以下など読んでいただいて。

Model View Controller - Wikipedia

MVCとは【Model-View-Controller】 - 意味/解説/説明/定義： IT用語辞典

読んで字のごとく、MVCはアプリケーションの構造をModelとViewとControllerという３つの概念に分けるものなのですが、これらの開発過程でTDDを生かして進めていくとかなり有効。というのも、それぞれの利点がうまく重なっているんです。

まず、私が考えているMVCの利点は次のような所。

MVCそれぞれにクラスが独立していて、作成するコードの単位が明確である。
メソッド単位、アクセサ単位で処理を隠ぺいできるので、既存コードへの影響が少ない修正作業、リファクタリングをすることが出来る。

そして、TDDの利点は次のような所。

仕様が理解できているか、抜けが無いか、自己確認が出来る。
リファクタリングや仕様変更によるデグレードを防ぐことが出来る。
メソッド単位、クラス単位の小さなテストコードを積み重ねるので、全体がどれくらいで、今できているのがどれくらいなのか判り易く、進捗を取りやすい。

つまり、それぞれの利点の共通点は、

プログラムコードにしろテストコードにしろ、実際に作業する単位が小さい。

こと。ここ、以外と大事。独りでちまちま作るにしろ、チームで作業を分けあうにしろ、TDDで作り上げていくMVCのアプリケーションは、小さな単位を積み上げていくってことが同じだから作業に無駄がない。実際に、たくさんのテストコードがGreenになるのは楽しいし＜結局そこか（笑）

効率良いTDDをするために

小さな作業単位を積み上げていくのは良いけれど、それらをもっと効率的に確実にできる方法はないのでしょうか？

例えば、チームでMVCそれぞれを担当して並行してすすめる、とか。恐らくは「独立したテストコード」を作成できれば、その理想に近づく事は出来ると思うのですけれど……。

MVCは独立しています、といっても、それぞれのクラス、メソッドで動作するプログラムは動作の前提条件や変数の内容などで密接な関係があることに違いありません。こっちが出来てないと、データこないじゃん、データないじゃん、ということはフツーにあるわけで。

そこで、テスト用クラス、Mockというクラスの考え方が出てきます。

極論、Modelのクラスを作成したい時には、Modelクラスだけがテスト出来れば良いわけです。その他のViewクラスやControllerクラスが、未実装だったり、まだバグがある状態だだったり、そんな状態で使っていたら、本来のModelクラスのテストはいくら頑張っても効率が上がらない。だから、その対策として、Modelクラスの目的の動作に必要な前提条件、テストデータ、それらを備えたクラス、Mockクラスを用意するのです。それを使う事で、前提条件がそろった状態で実行できますから、自分は必要な最低限のModelクラスの動作だけをテストコードに記述すればよいですね。

具体的に、データベースからレコードを取得して一覧に表示する、を例に考えると、

データベースからデータを取得する。
一覧表示用のリストデータに加工する。
リストデータから一覧表示を行う。

とMVCの単位で大まかに分けることができます。実際にはもっと色々とあるかもしれないけど、例なので大雑把（笑）。この時にTDDしよう！と思ってテストコードを書き始めた時、１を作って動作できたら、２を作って、２が動作出来たら３を作る、とやっていかないと、必要な前提条件（データ）がそろわない。

でも、

データ取得ためのデータを提供するデータベースのMock
リストデータ加工するためのソースデータを持つクラスのMock
リスト用データに加工済みのデータを提供するクラスのMock

がそれぞれにあれば、１～３のクラスを並行に作業可能。自身以外の必要なクラスはMockに任せてしまってるから、本当に自分が作りたいクラスとメソッドの動作を検証するだけのテストに特化でき、TDDのサイクルも早くなります。

つまり、Mockクラスを使う事で「独立したテストコード」が可能になるんです。

ちなみに、実際にテスト用Mockを使ったテストを行う時、良い仕事をしてくれるのがInterfaceクラス。Mockに置き換えたいクラスがInterfaceを持つことで、呼び出し側はMockなのかそうでないのか、意識する必要がなくなります。DI（Dependency Injection）できるフレームワーク上でのTDDなら、なおのこと、必要に応じてMockを注入できるからお勧め。

TDDの肝

こうなってくると、Mockを作成する＝Mockの内容に仕様と齟齬があったら、なかなか大変なことになるのでは？と思いませんか？

Mockの作成もさることながら、テストコードの作成にしてもそうです。テストコードの品質＝作成されるアプリケーションの品質、と考えても過言ではないでしょう。あくまでもこれは経験則ですが、TDDの肝は、言語やフレームワークに関係なく、まず仕様の理解が必要不可欠であり、それをいかにテストコードに反映できるか、だと思っています。なんて偉そうに言ってても、まだまだ私も修行中の身、仕様理解できてない、勘違いしてた、がよくあってorz。

TDDは小さな単位でプログラムコードの動作を検証でき、それを積み上げていくことで磨かれていく開発手法です。MVCパターンとも相性がよく、うまく使えば非常に有効な手段でもあります。

というわけで、私の記事は終わりです。最後に、TDDに携わるようになってから覚えた、自戒の意味をこめて、この言葉を。

「書いていないテストコードにバグがある」

WCATのコマンドラインオプション

片桐　継（Tugu Katagiri） — Thu, 09 Jul 2009 17:19:00 GMT

どうも、ＷＣＡＴってやつは、wsfファイルに色々とコマンドをくっつけて動かすらしい。

一個のファイルでいろんなことができるようになっているようなので、コマンドを整理しないと困りそう。

-clients	:	コントロールしたいWCATクライアントのIPアドレスとか名前とかをカンマ区切りで列挙
-terminate	:	すべてのWCATクライアントを停止
-update	：	-clientsで指定したWCATクライアントに、DLLとEXEをコピーしてWCATクライアントとして登録、使用できるようにする。クライアントのコピー先は「￥￥コピー先クライアント￥admin$￥wcat」となるので、アクセス権があるかどうかを確認すること
-run	:	WCATクライアントを開始
-setclients	:	-clients パラメータと一緒に使用すると、コントロール側では、レジストリ「HKLM￥Software￥WCAT￥clients」に情報を登録更新。パラメータがない場合には、同レジストリを初期化してデフォルト値（localhost）に戻す
-showclients	:	レジストリ「HKLM￥Software￥WCAT￥clients」に登録されているクライアントを表示
-stdout	：	ログの標準出力先を指定。ファイル名を使用しない場合には画面に表示される
-stderr	：	エラーの標準出力先を指定。ファイル名を使用しない場合には画面に表示される
-help	:	ヘルプを表示

ってここまでが、WCAT.wsfで使用するおもなオプション。で、これの大変なところは、この後に、WCATコントロール用の専用オプションスイッチもつけられるってところ。これがまたたくさんあって、どうしたもんだかと、ちょっと考え込んじゃった。

WCATコントロール（wcctl.exe）のコマンドラインオプション

いくつかのカテゴリに分かれているらしい。入力系、設定系、シナリオ系、出力系、その他、くらいかな。

入力系オプション（Input File　Parameters)

-clientfile	:	-t に省略可能。必須。テストシナリオファイルを指定（テストシナリオファイルについてはまた後で）
-settingfile	:	-f に省略可能。必須。設定ファイルを指定（設定ファイルについてはまた後で）

設定系オプション（Setting File Override Parameters）

設定ファイルの中にも書けるんだけど、実行時にスイッチで渡すことで動的に変えることができるらしい。

-virtualclients	:	-v に省略可能。ファイル内で指定していない場合には必須。１台のWCATクライアント上で、何ユーザー分の仮想コネクションを発生させるかを数字で指定。WCATが５台あって、３を指定していたら、５×３で15コネクションの負荷テストが行える
-server	:	-s に省略可能。ファイル内で指定していない場合には必須。テストを行いたいWEBサーバーをドメインURLもしくはIPアドレスで指定。カンマ区切りで複数指定も可能
-port	:	-p に省略可能。WCATクライアントがテスト開始時に、対象サーバーへ接続テストを行う際にポート番号を変更したい場合には指定。通常はhttpポート（８０）を使用
-comment	:	-k に省略可能。テスト結果に含めておきたいコメントがあれば指定

シナリオ系オプション（Scenario File Override Parameters）

シナリオファイルの中にも書けるんだけど、実行時にスイッチで渡すことで動的に変えることができるらしい。

-warmup	:	-w に省略可能。ファイル内で指定していない場合には必須。全てのクライアントのロード開始準備が終了しても、この時間が指定されている場合には、WCATコントローラはテスト開始を待機させることができる
-duration	:	-uに省略可能。ファイル内で指定していない場合には必須。warmup終了後、WCATクライアントがロードテストを開始するまでの待機時間を秒で指定
-cooldown	:	-c に省略可能。ファイル内で指定していない場合には必須。ロードテスト終了後、warmupを行うまでの待機時間を秒で記録。この間にテスト結果を記録される。通常は20秒。

って、ようるに、ウォーミングアップして、テスト開始！よーいどん！まで待機して、仕事終わったらクールダウンして、ハイ次！って繰り返す時のそれぞれの時間を指定してるってことだね。

出力系オプション（Ooutput File Parameters）

出力用の設定。デフォルト値があるので、別に指定はいらないかもしれない

-output	:	-o に省略可能。デフォルトは　log.xml。WCATインストールディレクトリに存在
-report	:	-r に省略可能。デフォルトは　report.xsl。WCATインストールディレクトリに存在

その他系はまたどっかで。ふー、列挙だけで疲れたｗ

WCAT起動の準備

片桐　継（Tugu Katagiri） — Wed, 08 Jul 2009 15:21:00 GMT

WCATを使用する前の最初に一回だけのおまじない。これは、WCATコントローラとなるPC（サーバー）で使用。

Administratorでログイン
コマンドプロンプトを起動
WCATのディレクトリに移動
「cscript //H:Cscript」と入力

これで、動作準備OK。次に、このマシンで行うWCATクライアントを登録

wcat.wsf -terminate -update -clients localhost

もし、いくつかのPCにWCATが分散する場合には、-clientsのパラメータに localhost,192.168.1.3,hogepc とかいった感じでカンマ区切りで追加してあげれば大丈夫。

初めてこのコマンドを動かす場合、このあと強制的にサーバーが再起動！！

だから、他のアプリケーションとか立ち上げてたら注意してね

コマンドプロンプト画面がないのは、そのせいなのorz

WCATの３つのテスト手法

片桐　継（Tugu Katagiri） — Wed, 08 Jul 2009 14:58:00 GMT

さて、まだ実はドキュメントを読んでいるわけなのですが、こちらにメモをためていくことにした＜おい

WCATには３つのテスト手法があって、それぞれにメリットデメリットがあるみたい。で、思ったことをつらつらと。

１台のマシンで行う（Single Machine Environment）

テスト用のすべての要素（WEB、DB、WCATコントローラ、WCATクライアント）を一台に入れてしまう方法。

テストに使用する資源は１台で済むのでお手軽。

ハイスペックマシンだと計測結果と実地結果の差異は小さいだろうけどスペック低いと本来のパフォーマンスが得られない分信頼性が下がりそう。

２台のマシンで行う（Dual Machine Environment）

テスト用の要素を（WEB）と（DB、WCATコントローラ、WCATクライアント）に分ける方法。

ネットワークの負荷も視野に入れてテストを行える分、こちらの方がより現実的実地に近いWEBサーバーのパフォーマンス計測が可能。テストに使用する資源が複数になるので、準備が大変だけど。

個人的には、Hyper-V上にWEBサーバーと計測用PCを作るのがお勧め。ヴァーチャルネットではあるけれども疑似的なネットワーク負荷も計測できるし。ただ、負荷テストなだけに、ホストサーバーマシンにそれなりのスペックが必要になっちゃうけど。

たくさんのマシンで行う（Multiple Machines Isolated Environment）

その名の通り、（WEB）、（DB）、（WCATコントローラ）、（WCATクライアント）×いっぱい、の構成で行う方法。

大規模なWEBサービスの負荷テストなら、これくらいのものが必要になるのだろうと思う。個人的には、これも、WCATクライアント全部Hyper-Vしちゃったら実質４台ですむなぁとつらっと思ったりした。

てなかんじの３種類。まぁ今回は、Hyper-V上に１台構成のSimpleで触ってみようと思う。

ゲストマシン（テストサーバー）

Windows2003ServerR2 メモリ３G

SQLServer2005　Enterprise

IIS 7.0

ちなみにHyper-Vホストマシン

AMD 5200(DualCore)

メモリ８G

の自作機

うん、がんばってみる。

WCAT、起動！

片桐　継（Tugu Katagiri） — Fri, 03 Jul 2009 14:45:00 GMT

最近のダブルキャットといえば、しゅうたんとみずきちゃん。

さて、そんなこんなで、ひさしぶりにASP.NETで作られたサイトをゴリゴリとストレステスト中

サーバースペック：Hyper-V上のWindows2003 server R2(64Bit)

に対して、WEBアクセス負荷テストをしてみたくて、WCATを使ってみることにした。

WCAT、とは？

Microsoftの開発チームが使っているテストツールらしい

[HOW TO] 無償の簡易 Web 負荷ツール WCATの使い方
 http://social.technet.microsoft.com/Forums/ja-JP/iis7ja/thread/c49f277a-f9e3-4e96-8634-72259edf2730

でもって、さっそくダウンロードして、msiからセットアップ。

しても、メニューにも登録されないし、デスクトップにもでません

だって、これ、スクリプトベースで動く、CUIアプリだもん。

まぁCUIでもなんとかなるさ、インストール先は普通なら、「Program Files\WCAT」なので、これを覗く。

という風に、exeファイルが３つにスクリプトファイルひとつ、あとはサンプルに、xslファイル。

まぁxslはSandcastleで見慣れたファイルなのでここはおいといて、と。

とりあえず、DOCファイルを読む、でわかったこと。

wcclient.exe：クライアント側からストレステストする時のプログラム

wcctl.exe：サーバー側からストレステストする時のプログラム

wcutil.exe:ストレステストで作成したログを整形するっぽい？

くわしくはもちっと、がんばって読んでみることにする

SQLCLR　ストアドプロシジャをデバッグする

片桐　継（Tugu Katagiri） — Mon, 30 Mar 2009 22:15:00 GMT

SQLServer2005でSQLCLRストアドプロシジャを作ってて、何が大変って、デバッグだった。それもステップ実行による、デバッグ。

いろいろと方法があるのだけれど、結局、「現場でいちばん有効だった」方法がこれだったので投下ｗ

まず、思い切ってクラス化構造にしてしまうというのがこのお話のポイント。

こうすると、クラスの単位でデバッグができるので、処理の確認の範囲がぐっとせまくなるんだよね。

１．クラス化構造でロジックを作る

２．作ったクラスをコンソールアプリ or UnitTest で動作確認する

３．確認を終えたら、ストアドプロシジャのメイン処理からそのクラス処理を行う

って作ると、２．を作った段階で、クラスの処理内部の動きは確認済になるわけだから、動かなくなる、エラーがある、としたら、３．のクラス呼び出し側にかかわる部分、と絞り込めるわけ。

最初は、必死にCLRデバッガで止めてやってたけど、行き着いた先はここだったorz

でも簡単にはこの手順ではいかない。特に、SQLServerCLRのためにあるとも言えるような処理ロジックを含む場合には、それを代替してテストして、ストアドプロシジャ環境に持ってきてから動かしてみる、という手順が必要。そのためにも、ストアドプロシジャ独自で使われるルール（Partialクラスで作るトアドプロシジャクラス、接続文字列）とオブジェクト群（SqlContextクラス処理）の使いどころと処理スコープについて知識を得た上で、自分の作りたい処理にあてはめながら明確に切り分けられるようにしておくといいよ。

くわしくは、MSDNのここかな？

データベースエンジンの .NET Framework プログラミング

Imports System
Imports System.Data
Imports System.Data.Sql
Imports System.Data.SqlTypes
Imports Microsoft.SqlServer.Server
Imports System.Data.SqlClient

Partial Public Class StoredProcedures 
    <Microsoft.SqlServer.Server.SqlProcedure> _
    Public Shared Sub GetVersion()
        Using connection As New SqlConnection("context connection=true")
            connection.Open()
            Dim command As New SqlCommand("SELECT @@VERSION", connection)
            SqlContext.Pipe.ExecuteAndSend(command)
        End Using
    End Sub
End Class

これはMSDNサンプルの、SQLServerのバージョンを返すCLRストアドプロシジャ。この中にはSQLServer用CLRのために使われているオブジェクトや宣言が混じっていているのね。なので、デバッガでステップ実行しようとするといろいろと設定したりして、それでも止まらなかったりでなんかストレスｗ。

でも実は、この処理はこう書いても動きは同じ。

Imports System
Imports System.Data
Imports System.Data.Sql
Imports System.Data.SqlTypes
Imports Microsoft.SqlServer.Server
Imports System.Data.SqlClient

Partial Public Class StoredProcedures
    <Microsoft.SqlServer.Server.SqlProcedure()> _
    Public Shared Sub GetVersion()

        Dim versionGetter As New GetVersionInfo
        SqlContext.Pipe.Send(versionGetter.GetVersionFromServer)

    End Sub
End Class

Public Class GetVersionInfo
    Private _myConnString As String = "context connection=true"
    Property SQLConnectionString() As String
        Get
            Return _myConnString
        End Get
        Set(ByVal value As String)
            _myConnString = value
        End Set
    End Property
    Public Function GetVersionFromServer() As String

        Dim retStr As String

        Using connection As New SqlConnection(_myConnString)
            connection.Open()
            Using CommandStr = connection.CreateCommand
                CommandStr.CommandText = "SELECT @@VERSION"
                retStr = CommandStr.ExecuteScalar().ToString
            End Using
            connection.Close()
        End Using

        Return retStr

    End Function
End Class

で、こうなると、GetVersionInfoクラスとして分離されちゃうわけなので、こういうテストロジックが書けるようになる

Module Module1

    Public Sub main()

        Dim versionGetter As New GetVersionInfo

        versionGetter.SQLConnectionString = "接続文字列"
        versionGetter.GetVersionFromServer()

    End Sub

End Module

これなら、デバッグできるじゃない？　で、GetVersionInfoクラスの処理の動作を確認できてから、実際のGetVersionストアドプロシジャを動かしてみれば、正常に動作しなかったとき、ストアドプロシジャ関連のところで問題があるのでは、と絞り込みやすくなる。サンプルは小さい処理だからいいけど、大きな処理になればなるほど、小さな単位で動作を保障できるように作っていくのがとっても大事だと思うの。

さて、今の現場も残り１日。いろんなことを勉強して、いろんなことを知って、いろんなことがあった。一つ一つが本当に大切なスキル。

ありがとうございましたです。心から、感謝。

てすと☆番外

片桐　継（Tugu Katagiri） — Fri, 27 Jul 2007 11:27:00 GMT

もってけ！とは言わない（大汗）

ネタ元はこちら。片桐、一刀両断されてるし（笑）
というか、なかせんせのおっしゃるとおりで、前提からしてベクトルずれてるやんという話だとおもってみるテスト
なので日記であげてみるデスよ（＾＾；

プログラミングして、コンパイルして、テストケース作って、仕様書書いて……かくして出来上がってくる単体テストの精度や結果、それを証明する成果物は「動作結果を証明するもの」であって、「品質を証明するもの」とは別だと考えるので、ここでベクトルがすでにズレまくりんぐ。「テストしやすいコード」「テストしづらいコード」のこだわりって、必ずしも必要じゃないね的所がすでに（ｒｙ　開発規模が大きかったり、納期がタイトだったりするとそれよりも「確実に動作が確認できる」ことの方が先決になる場合もあるし（＾＾；
　単体は所詮「単体」で、それがシステムの品質を証明することにはならない。多分ここもベクトルが違ってて私の考える品質は「システム」に対して掛かる修飾子（大汗）そのプログラムがそれこそ「単体」で「全体」の動きであるのなら、確かにその「単体の動作保証」＝「品質の動作保証」だと思うけれど、ぶっちゃけ、車の一部品の品質保証が取れたからって車全体の品質保証にはならない。確実にいえるのは、その部品自身は発注されたとおりの動きがとれてますよってことが明らかになってます、証拠もありますですよ、ってことだけ。そこが私の中では前提になっちゃってたからベクトルずれズレなんだと思うのです。むぅ。
　テストしやすいコードで作られたプログラム達が積み重なって寄り集まって、キング「テストしやすいコード」になったとして、それが「品質保証完璧だぜ」コードになるかというとそれは違う。それぞれが正しくても、全部を通したときにやっぱりおかしい、なんてことはザラで、そこには全体を通したときの「仕様バグ」や「方式バグ」が存在するわけだから、単体で品質保証＝システムの品質保証にはならないし、そういう考え方で進めちゃうとハマッチャウから危ないと思うの。
　単体＝プログラムの動作が仕様とあっていることを証明するテスト≠品質保証のテスト　は私の中では変わらないですよ……むぅ。じゃ、品質保証のテストは……？　規模によるけど、総合テストはまさしくそのためのテストだと思ってますです。なので単体では無いのです……。

単体テスト　レベル１　その２

片桐　継（Tugu Katagiri） — Wed, 04 Jul 2007 13:37:00 GMT

　レベル０
http://blogs.wankuma.com/esten/archive/2007/06/18/81072.aspx
http://blogs.wankuma.com/esten/archive/2007/06/19/81308.aspx

ちょっと間が開いたのですが、前回の続き

「単体テストは全てのプログラムコードが処理されたことを証明し、書いていないプログラムコードの処理によって起きうる結果についても検証するテストである」というお話をしました。つまり、書いていないプログラムコード≒例外処理、ということが言いたかった前述だったのですが、先輩方のプログラムコードから単体テストを任される場合、ほとんどの場合「これら例外処理がプログラムコードに含まれている」ことが多いことに気づくと思います。例外処理を意識したプログラムコードが書けるかどうかも、プログラムスキルの一つといっても過言ではありません。レベル０でお話したとおり、「全てのプログラムコードの処理を確認する」単体テストを行えば必然的にこれら例外処理のロジックも通らなくてはならないのですから、例外処理を意識したプログラムは、テストを依頼する場合にテストする側が読み取らなくてはならない「書いていないプログラムコードの動作」について考慮する範囲が狭くなり、テストの難易度も下がる、と良い事づくしですね。

と、ちょっと話はそれましたが（汗）、レベル１の最後として、例外処理のテストについてもう少し突っ込んでみましょう。

いかに例外処理を発生させるのか

　VisualStadio等のコードデバッグを可能とするツールの場合、イミディエイトを使うと簡単に実現できます。テスト直前のロジックでブレークポイントを設定し、止めた後に、判定の変数の中身を変更してしまうもしくは次の処理ロジックラインを目的の処理まで変更する、ことができるからです。また、UNIX、AIX等で使用されるDBXも同じく変数の中身の変更（assign コマンド）を行うことで擬似的に処理例外を起こす事ができます。
　変数の中身の変更は、NULL値を設定、もしくはアドレスをNULL値に設定、とするとほとんどの場合例外処理を発生させることになるはずです。

例外発生時の処理結果保存

　さて、そうやって何とか発生させたエラーです、確実に証拠を取りましょう。ダイアログが表示される場合にはダイアログをキャプチャーしてしまうのが最も手っ取り早く確実です。「ALT」＋「PrintScreen」キーを同時押しすると、現在、最前面にあるダイアログだけが画像データとしてクリップボードに送られます。ペイント等で貼り付けて確実に残しましょう。画面上にエラーが表示される場合のみの場合も同様です。大切なのは「こうなった時にはこういう結果が出る」ということを確実に証拠として残しておく、ということです。習慣づけておくと良いですよ。

今度、レベル２はその単体テストで作成しておくべき「テスト仕様書」と「テスト結果」について、ちょこっと話……してもいいかな？＜おい