PartCoverとNUnitについて

PartCoverとNUnitを組み合わせて使用することが殆どであると思うので、NUnitを用いたPartCoverの設定は、以下のとおりです。

・Executable File:実行ファイルを設定する(NUnitの場合は、NUnitの実行ファイル名)

・Working Directory：コードカバレッジを測定したいフォルダの位置（例：テストコードのdllの出力フォルダ）

・Working Arguments：コードカバレッジを測定するdllなど

・Rules：測定するDllやファイルなどで、記述は+*ですべてのファイルを追加。+[アセンブリ名]で指定する。+*で記述すると、NUnitのアセンブリも追加されてしまうので、基本は測定したいアセンブリ名を指定。（例：+[*cs*]*など)

後は、Startボタンを押して、NUnitをRunで走らせて、終了したら、NUnitを終了させれば、測定開始となります。

PartCoverについて

.NETのコードカバレッジ（網羅率）を測定するフリーのツールとしてNCoverがありますが、有料化されてしました。そこで、フリーのツールである、PartCoverについて調べてみました。

PartCoverは、判定条件網羅になります。判定条件網羅とは、判定条件で真となる場合、偽となる場合をそれぞれ少なくとも1回は実行するになります。

つまり、以下のような場合です。
条件1：真、条件2：真、判定条件：真
条件2：偽、条件2：偽、判定条件：偽

ただ、これには問題点があり、実装の仕方によって100%になる場合とならない場合があります。

数学1が80点以上または国語が65点以上なら「合格」、それ以外なら「不合格」といったプログラムを作成した場合

ソースコード1：
public void 合格か
{
　get { return 数学1>=80 || 国語>=65; }
}

ソースコード2：
public void 合格か
{
　get
　{
　　if (数学1>=80 || 国語>=65)
　　　return true;
　　else
　　　return false;
　}
}

テストコードを、数学1が真、国語が真になるようなパターンで作成した場合に、
ソースコード1の場合には、カバレッジが100％、ソースコード2の場合には、50％になります

ツールの設定は別のところで説明をします。

C#の縦書き文字

C#における文字を描画する際に、DrawStringメソッドを使用します。

これを縦書き文字にする場合には、StringFormatのDirectionVerticalを使用すれば、簡単に縦書き文字にすることができます。

ただし、複数行の文字を縦書きにする場合には、縦書きにすると、右方向に90度回転すると思っていると、少々違っています。

文字を左から右方向に読みようになってしまいます。

複数行の文字を縦書きにする場合には独自に実装する必要があるので、注意が必要です。

Androidはちょっとやっかい

Androidでカメラを起動したり、カメラで撮影した画像一覧を取得するためには色々と面倒だということがわかりました。

エミュレータで動作させていると、カメラの画像一覧を取得しようと思って、調べていると、SDカードを挿入しろと言われました。

SDKには、カメラを起動するためのものはありますが、エミュレータで動作させるのには色々と面倒なことをしなくてはならないということがわかりました。

まだまだ私の知識が不足しているので、できないことが多いです。

しかし、まずは自分で試すことが重要なので、調べて苦労していこうと思います。

日本にはあまり無いな

先日、会社で話をしているときに、USB接続のミサイルランチャーがあるということを聞いて、そのことを知らなかったので、少し調べてみました。

USB接続のミサイルランチャーというものは、スポンジがミサイルになっていて、PCでどの方向に打つかを決定することができるオモチャです。

色々と調べていると、どうも海外でUSBグッズを色々と作成している会社があり、それを数年前から日本で発売しているようです。

値段も非常に安価であるので、ちょっと欲しいなと思いました。

使用用途としては、ビルドエラーになったときに、ビルドエラーになった人に向かってミサイルが飛んでいったら面白いなと思います。

間違いなく、経営者や上司に遊ぶなと怒られると思いますので、家で使用することになると思います。

コレを調べていて思ったことは、日本には海外のように遊び心があるようなものを作成する会社というのはまれであるなと思います。おそらく国の文化の違いがあるのが要因でしょうが、こういった会社が日本にもあっていいなと思います。

感覚が戻りつつある

今日、会社の人たちとソフトボールを行いました。

久しぶりのソフトボールだったので、非常に疲れましたが、気持ちのいい汗をかくことができました。

ソフトボールが終わった後に、軟式のボールを持っていったので、ピッチング練習をしました。

最初にサイドスローから投げて、何かボールに勢いがないなと思い、昔のオーバースローに戻しました。

どうしてもまだ感覚が昔と違うなと思って、腕の位置の意識を上から投げ下ろすようにしたら、だんだんと良くなってきました。

そういえば、昔投げていた感覚に近いものがあり、練習をしていくうちに感覚が戻ってきました。

今回、たまたま投げたことで感覚を取り戻してきましたので、たまには練習をしなくてはいけないと感じました。

テストエンジニアのあるべき姿

テストケースの作成指導や、自身でテストケースを作成している際に、同値分割や境界値分析を用いて、行います。

ここで、私なりの疑問があります。

それは、コレをテストエンジニアがテストケースに盛り込んでいきますが、本来これはプログラマがテストを行う時点で、確認がされているし、ここでバグが入っていることは少ないのではないかと思います。

プログラマのテストで漏れることもあるでしょうが、少ないと思います。

テストケースの作成の基本は少ない項目数でより多くのバグを発見することなので、テストエンジニアは、プログラマ以上に、処理を考えながら、処理の漏れや考慮不足をついたテストケースを作成するのがあるべき姿ではないかと思います。

では、なぜ、書籍などでこのようなことが記述されていないのかが疑問が残ります。

答えはわかりませんでした。

頭の切り替えは非常に疲れる

最近、テストリーダーをしたり、プログラマをしたりと多忙な日々を過ごしていて、特に感じることが、作業の切り替えというのは非常に難しいなと思います。

特に、プロジェクトを複数掛け持ちで作業をしているとそのように思います。

最近は、2つのプロジェクトのテストリーダーをしながら、1つのプロジェクトの修正をしていると、本当に頭の中で作業を切り替えないと、何をすべきかを常に考えているので、非常に疲れます。

そういった場合には、ある程度割り切りというものが必要になってきます。割り切りといっても、この時間はこの作業に集中しようというような割り切りです。

そうしておかないと、自分の中で、切り替えができなくなってしまうので、どれも中途半端になってしまいます。

そうしないためにもこのような対処が必要になってきます。

現在は作業の割り振りを見直したので、解消されましたが、そういった場合の対応もできるようになってきたなと思います。

昨日は散々でした

昨日、野球をしてきました。久しぶりに、フルイニング出場して、こんなに長かったのかなと思います。

結果はというと、サヨナラ負けをしてしまいました。最後に、自分がライトを守っていて、本来は内野に返せばいいのに、タッチアップをしてくると思い、ホームに投げて負けてしまいました。

打席でも散々で、4打数ノーヒット（内2三振）でした。2打席目に、ワンナウト満塁で打席が回ってきて、力んでしまい、ゴロを打つ場面で、ポップフライを打ってしまいました。

本当に昨日は散々な試合でした。

ただし、よかったこともあります。それは、ボールを投げたときに、非常にキレも勢いも良かったことです。筋トレの成果が出ているのかなと思います。

提供し続けなければいけない

ソフトウェア開発をする上で、仕様検討の材料で、紙芝居を作成したり、モックオブジェクトを提供したりして、常に仕様決定者が、評価できるものを提供し続けなければなりません。

例えば、最初は紙芝居程度のもので、かまわないと思います。それが合意できたら、操作感などをつかむためには、ある程度動作するものを提供しなくては、評価することもできませんし、また、アーキテクチャで問題となる箇所も早めに発見することもできないので、ある程度は動作するものを提供しなくてはなりません。

それが仕様が決まらないからといって、待っていたのでは、待ちの無駄ができてしまうので、非常に効率が悪い開発作業になってしまいます。

常に私達は、仕様決定者が評価できるものを提供し続けなければなりません。