ユニットテストとアサーションをどう扱うのか？

　事前条件、事後条件、不変表明をチェックするためにアサーションを使用する技法が一般化しています。これは防御的プログラミング／攻撃的プログラミングの一種であり、趣味と実務の違いを如実に表していると思います。というのも、初心者用のプログラミング本ではかかれないものの、多くのプロが実務で使用しているからです。初心者用のプログラミング本で書かれていないので、初心者やアマチュアはアサーションの重要性が分からないと思いますが、実務でアサーションの使用が一般化しており、それは非常に重要な技法だと考えて下さい。
　初心者のために簡単に説明すると、バグを減らすために使用する技法です。大体こんな感じでアサーションを使用します。

#include <assert.h>
int foo( int value ) 
{
    int result;

    //事前条件
    //引数は0以上でなければならない
    assert( value >= 0 );
    
    //何らかの処理をして戻り値を導出する
    result = value;

    //事後条件
    //返す値は-1以上でなければならない
    assert( result >= -1 );

    return result;
}

int main()
{
    //制約違反！
    //foo( -10 );

    //OK
    foo( 0 );
    return 0;
}

これはC言語を使った非常に簡単な例です。実務でこの様な関数は使用しませんが、雰囲気は伝わると思います。
　テストにはもうひとつ、有名かつ頻繁に利用される技法があります。それは、ユニットテストです。大半の人がユニットテストを書いている事でしょう。特にJavaプログラマは殆どの人がJUnitを使用していると思います。
　ここで一つの疑問が生じます。アサーションとユニットテストをどのように扱うのかです。アサーションを使用した技法は一見、ユニットテストと相性が合いません。事前条件、事後条件、不変表明の3つのチェックをソースに一切書かず、テストプログラムに記述すれば可読性が向上して良いと考える人がいても当然です。特にJavaや.NET系の言語は例外処理を使用する事もあり、アサーションをどのように使用するのか悩む人が多いでしょう。
　私も悩んだのですが、今は両方の技法を使用した方がいいと結論付けています。その理由は設計意図とテストプログラムは別種のものだからです。プログラムに設計の意図を書くのと、テストプログラムを書くのは別の意味を持っている行為です。
　まず、アサーションの方ですが、これは設計の意図を示すものです。ただ単にエラーが発見できればいいというものではなく、設計者の意図を示すのが本意です。関数もしくはメソッドがどういった制約を持つのかは、明らかに設計に属する事柄なのです。
　一方、テストプログラムはバグの撲滅が本意です。テストプログラムを書くと、自然とオブジェクトデザインが明らかになったりしますが、それは副次的な効果であり、テストはバグをなくすために行う行為です。むろん下手なインタフェースはバグの元であり、テストとオブジェクトデザインは無関ではありませんが、だからと言って両方を詰め込むのは頂けません。集団作業で本来の意味とは違うものを詰め込むと、コミュニケーションを阻害する恐れが高いです。コミュニケーションに支障が生じると、バグの発生件数が多くなるのは言うまでもないでしょう。
　以上の考えから私は、設計の意図とテストを明確に分離するために、2つの技法を併用しています。ただし、プリプロセッサを併用しなくてはなりません。それが少し美しくないのですが、アサーションを使用した報告機能を用意しておくと、万が一運用時にバグが生じても解決が速くなるので利点があります。運用時に1つのバグもないのが理想ですが、絶対安全神話を唱えずに、もしバグがあっても解決できるように準備しておくのが当然だと言えるでしょう。
　この話題に限らず、分離性は大事だと時だと私は考えております。物事を分離しておく方が明瞭かつ単純に保てます。先の事を考えるのであれば、明瞭であるべきだというのが私の持論なのです。この記事が誰かのお役にたてば幸いです。

※注意:.NETの場合はアサーションではなくコードコントラクトを使用するべきです。

並行処理のテストを行うコツと心得

　テストで難しいのは並行処理のテストです。直列的なアルゴリズムとは違い、並行処理は決定不可能な実行順序で処理が行われるので、バグを再現するのも発見するのも困難です。そこで今回は、私が並行処理システムを分析・設計・実装した経験に基づき、並行処理をテストするコツを解説する事にしました。
　並行処理をテストする上で最も大事なのは知識です。並行処理の原理が分かっていないとテストが出来ません。これはテスト全般に言えることだと思うのですが、実行環境に関する知識がないと、バグが起こる状況が想像できないのでテストが行えません。テスタをプログラマ以下だと思っている人も見受けられますが、実際のところはプログラミング能力に差はありません。分かっていないものはテスト出来ませんので、テストの際にはプログラミング能力が要求されます。
　並行処理の知識を身につければ後は比較的簡単です。システムをクラックするつもりでテストをします。クラックするつもりというと余り良い響きではありませんが、お客様の下でシステムがクラッシュするのを避けるために必要な事です。心を鬼にしてクラックプログラムを駆使します。一例として、標準入出力を使うオブジェクトをテストする場合の事を考えてみます。
　先ずは並行処理の結果が正常でない状況を考えます。標準入出力の様なオブジェクトは、静的な性質を持つのがクラックの糸口です。標準入出力が正常に動作しない状況は、入出力オブジェクトをスレッドごとに変え、変えた直後に実行するスレッドが変わる場面です。この様な状況下ではデータの整合性が保てなくなります（プログラムの例：.NETテストプログラミング入門5）
　繰り返しになりますが、並行処理のテストが難しいと言われる所以は、莫大な数実行順序の組み合わせが考えられる事が原因です。しかしテストでは、データが不整合になる状況を作り上げるだけでよいので、言われているほど難しくはありません。もちろん、直列的なプログラムよりも要求されるレベルは高くなりますので難しいのは確かですが、並行処理の知識さえあれば対応可能です。
　問題はテストをする為にテスト対象にコードを埋め込む必要がある事です。コードの美しさを考えた場合、これはあまりよい事ではありませんが、printデバッグをするのと同じです。それに避ける方法がないわけではありません。APIフックとリフレクションを駆使すれば、テスト対象にコードを埋め込む必要がなくなります。こうしたOSや実行環境のハックテクニックは、必要とされる知識レベルも高く、全ての状況下で実行出来るわけでもありませんが、美しいコードを作るために必要なテクニックです。
　テストは下っ端がするものだという先入観を持っている会社を見受けます。また、車輪の再発明をしないという言い訳を免罪符にして鍛練を怠る技術者も居ます。しかしながら、実際のところはシステムレベルまで要求される技術力を要する行為です。その上、現代に於いてテストは必須です。時代とともに要求される製品の品質が高くなります。私達技術者は、お客様のために常に切磋琢磨しなくてはなりません。

テストとリフレクションの素敵な関係

　皆さまはリフレクションを使っていますか？私は多用しています。使用する状況はテストです。テストプログラムでリフレクションを使用する事を当たり前だと私は考えています。その理由を今から書きます。
　私はリフレクションの機能を知った瞬間、テストプログラムに最適だと感じました。そして、実際にテストプログラムにリフレクションを使用して正しさを確認しました。テストプログラムにリフレクションを使用するメリットは3点あります。
　1つめの理由は、プリプロセッサを使用しなくてもよい事です。アクセス修飾子がパブリックでないクラスは、外部であるテストプログラムからはアクセスできません。そこでプロプロセッサを使用して、「デバッグ中はパブリックにアクセスする」とコーディングする方法が多々見受けられます。その方法は最適化されたリリース用製品をデバッグ出来ないという問題があります。最適化を施したプログラムは、デバッグ用プログラムと違います。ですから、リリース用製品もテストしなくてはなりませんが、プリプロセッサを使用する方法ではテスト出来ません。これは非常に問題です。リフレクションを使用すれば、プライベートなクラスに対してもテスト出来ます。デバッグ用とリリース用の両プログラムを同じテストプログラムで実行できるのは大きなメリットです。
　この考えを元に、TESTが定義されていたらアクセス修飾子をパブリックに変える方法もあります。そうすれば、プリプロセッサでもデバッグ用とリリース用で同じプログラムが使用できると思われるかもしれません。しかしながら、その方法は、プリプロセッサをちりばめる結果を生み、ソースコードの可読性を低くします。それを防ぐには、プリプロセッサ使用に関するコーディング規約を追加せねばなりません。コーディング規約は増えるごとに守られる確率が低くなり、余計な労力が必要となります。余計な労力を費やさないためリフレクションの方がよいでしょう。リフレクションがない言語は仕方がありませんが、リフレクションがある言語で非生産的な事をする意味がありません。
　2つめの理由は、拡張性が高いテストプログラムをプログラミングできる事です。人間は間違いを起こします。テストファーストでない開発チームはもちろんのこと、テストファーストを採用している開発チームであってもテストプログラムを忘れる可能性があります。リフレクションを使用しない場合、コードカバレッジを測定して発見する事になりますが、それでも人間は間違える可能性があります。それに加え、テストコードが多ければ多いほどテストの負担が大きくなり、結果として放置される可能性が高いです。それを防ぐ良い方法は、リフレクションを使用して拡張性が高いメタプログラミングをする事です。
　リフレクションを使用したメタプログラミングでは、テストプログラムを変えずに新しく追加されたメソッドにも対応できますし、同じテストパターンのプログラムを一つのプログラムで対応できます。テストプログラムは同様のプログラムが多くなる傾向があります。同じテストパターンのテストコードをコーディングするのは無駄な作業です。作業効率を高める為に、一つのプログラムで多くの状況に対応しましょう。
　3つめの理由は想定外を減らせる事です。ニュースを見ると、ここ最近「異例」という言葉と「想定外」という言葉が連呼されています。私はその言葉に強い不快感を持っています。何故ならば、想定しない事を免罪符に掲げていますが、その水準が限りなく低くなり、プロならば考えなくてはならない事まで想定外の一言で済ませられているからです。そして、「異例」という言葉を連呼する行為は、過去から何も学んでいない事を意味しています。私は技術者なので、想定外を想定する事と過去から学ぶ事は当たり前だと考えております。リフレクションによるメタプログラミングを活用すれば、想定外を検出するテストプログラムをプログラミングする事が可能となります。それに加え、メタプログラムを考える事により過去のテストプログラムを観察する姿勢が身に付けられます。人間は問題を抽象化する事により生産能力を高められます。
　リフレクションをテストプログラムで活用するメリットがよくわかったと思います。これはリフレクションに限った話しではありません。関数型プログラミングを活用してテストの生産性を高めることも可能です。要はどんな言語機能も活用するという事です。複数の言語を学び、言語の全ての機能を活用する場面を考えましょう。そうすれば、仕事の作業効率と質が高くなります。

テストの基礎知識

　このブログは、情報処理技術全般の知識を書く事を目的としているので、テストについても書きます。テストプログラミングは普通のプログラミングなのですが、やはりテストを行うには知識が必要となります。この記事では、テストを行う際に必要となる基礎知識を解説します。
　テストはプログラミングの後考えればよいというものではありません。これは、ウォターフォール型開発モデルがもたらした弊害の内の一つだと思うのですが、テストを後でやるものだと考え、上流でテストの事を考えない悪しき習慣が広まっています。しかしながら、テストは全工程で考えなくてはならないものです。システム開発を行った人ならば実感していると思いますが、バグは仕様書を作る段階で生みこまれる事が多いのです。また、テストは正しい結果が定められていないと意味がありません。何が正しいのか分からない状態では、テストプログラミングをする前にバグが発生していると言っても過言ではありません。これから各工程のテストについて書きます。
　システムの分析工程では全体像を早期に把握し、何が分析されていて何が分析されていないのかを常に把握せねばなりません。より専門的に言えれば、問題領域全体を定めた上で問題領域を分割し、各問題領域がどこまで分析されているのかを管理するという事です。そして、ユーザーストーリーが網羅されているかユーザーと共にチェックします。一番のシステムエラーはユーザーの要望を満たしていない状態です。それを防ぎ、後の工程でテストを行いやすくする為の基盤を整えなくてはなりません。そして、ユーザーストーリー自体が正しいのかもチェックします。これにより、開発者とユーザーのシステムに関する認識を一致させます。この作業はもちろんアジャイルにやるべきです。あらかじめ全ての問題領域を分析するのは不可能です。
　設計段階ではテストクラスの設計も同時に行います。オブジェクト指向ならばこの作業は非常に重要です。ユニットテストを無目的にやる現場も多いのですが、テストプログラムもまたクラスである事を忘れてはなりません。オブジェクト指向では、親クラスの制約や仕様は子クラスも満たさねばなりません。また、再利用しやすい保守性に優れたクラスを作るために、テストクラスの設計を作ることも重要です。何故ならば、テストクラスを考える事により、クラスの使いやすさが自ずと浮かび上がってくるからです。テストクラスも同時に設計する事によりテストの漏れを防ぎ、再利用しやすい良いクラスを設計できます。
　実装段階では、「単体テスト」「結合テスト」「統合テスト」の3段階のテストを行います。単体テストとは、クラスもしくは関数単位でテストを行うテストの事です。結合テストとは、複数のクラスもしくは関数が正しい結果を生むのかをテストする事です。最後に総合テストとは、システム全体が正しく動くのかをテストする事です。
　今回は駆け足でテスト全体について解説しました。詳細な解説は後日します。

テストは特別なものではない

　今、前から不思議に感じていた事をふと思い出したので書きます。多くのプログラマは、テストをなぜ特別視するのでしょうか？
上手く言えませんが、「TDDではGUIのテストがネック」などと兎に角テストを別のものとして考えているという気がしてなりません。
　しかしながら、私はテストをそこまで特別視した事がありません。何故ならば、テストプログラムも普通のプログラミングと同じだと考えているからです。
　先ほどの例でいうと、GUIテストもただのGUIプログラミングです。GUIもプログラムが動いているだけです。最近のGUIはオブジェクト指向で作られているから余計にそう感じます。昔の関数のコールバックよりも簡単です。
　コンピュータの全ては0と1で動いています。ですから、コンピュータにとって、人間が触る事とAPIで動く事は同じです。コンピュータは0と1をひたすら処理しているだけなので全ての出来事は同じなのです。
　そう考える私は、現場で「GUIの部分はテストファースト出来ないよな」などと聞くたびに違和感を覚えます。GUIのテストもGUIプログラミングなのですから、GUIのテストを出来ないという事は、GUIプログラミングが出来ないと発言しているのと同じです。「ボタンが人間によりクリックされたら・・・」と「ボタンをクリックするプログラムを実行する」のはどう違うのでしょうか？「人間は何をするかわからない」と人間のランダム性について述べる人はそれなりに説得力がありますが、ボタンをクリックしたらどうなのか仕様で決まっているはずです。それに人間には思考パターンがあるのでのランダム性には限界があり、コンピュータのランダム性には勝てません。乱数に偏りがないように気をつけながら、ランダムなテストプログラムを実行すれば済む話しです。ボタンがクリックされた時の仕様は常に、オブジェクトもしくはコードの状態に依存します。
　こういう事を言うと、想定外な事があると反論する人がいますが、それについてもテストを特別視しすぎる事の言い訳にはなりません。仕様には想定外がつきものですが、そもそもテストの目的は想定外を発見する事も含まれている筈です。原発事故などのニュースで「想定外」が連呼されているところをみると、日本人は想定外な事を考える事すらしていないという気がしてなりません。しかしながら、システムにとって「想定外」はバグ以外のなにものでもないので、想定外を検出するテストプログラムを考えるべきです。これは情報システム特有の利点です。
　大半の情報システムは本当の現実ではありません。そもそも、情報機器で現実をモデル化する目的は、現実では出来ない事を実行する事です。ですから情報システムに限って言えば、テストを怠る理由は殆どありません。テストプログラミングも普通のプログラミングと同じです。
　私は不思議で仕方がないので、この問題の真の理由を考えました。その結果一つの仮説にたどり着きました。それは、技術者の質が下がっているのが真の原因だという説です。何度も例に挙げているGUIプログラミングはRAD（Rapid Application Development）でお手軽にできるので仕組みを知らない人が多々見受けられます。仕組みを知らないから、GUIもただのコードの集まりだという発想に至らないのではないでしょうか？
　開発の生産性を上げる事は必要です。ですがそれは、知識がなくてもよいという事ではありません。何時の時代も人間は学習をしなければならないのです。知らない便利なツールに頼り学習を怠る時、人は大きな痛手を受けます。分からないからテストしないのではなく、正しくテストする為の知識を身につけましょう。