?もちろんテストなしのリリースは有り得ませんので、何らかの方法でテストを実施されていることでしょう。いった、テストを仕様・ふるまい記述手段として利用する「テストファースト」で開発を進める方式が浸透してきていますが、全てがその方式で開発される訳ではありません。進める際に有利に使える便利なツール「Turnip」を紹介します。解説に入る前に、「テストとは何か」ということを簡単におさらいしておきたいと思います。世界で『テスト』というとユニットテストの自動化の話が中心になりがちですが、それは広大なテストの世界の一部でしかありません。システム構築の世界でよく言われる「単体テスト」「結合テスト」「総合テスト」という考え方があります。Test)2テスト屋さんの世界では、次のように分類し各種テストや評価を実施する整理もあります。データ保全性評価そこにはあまり立ち入らないでざっと大きく分けると、「内部テスト」と「外部テスト」ということになります。内部テストと外部テストテストを内部テストと外部テストという観点で整理してみます。内部テストは実装者だけの世界、外部テストは実装者以外でもできる世界です。内部テスト内部テストはいわゆる「ホワイトボックステスト」で、プログラマが意図したとおりにプログラムが動作することを確認するテストのことです。具体的には、プログラマが変数の値を変えながらコードを直接実行して、期待する結果が得られるかどうかを検証していくことになります。ゲームプログラミングであれば、「キャラクターの経験値が特定の値になったらレベルアップする」ということを確かめるために、実際にプログラム内部のキャラクターの経験値を直接書き換えてみて、本当にレベルアップするかどうかを確かめてみるようなことが内部テストとなります。介して評価していきます。ゲームプログラミングを例にすると、先ほど同様「キャラクターの経験値が特定の値になったらレベルアップする」ということを確かめるために、実際にゲームをプレイしてみて経験値をためて、条件を満たしたらきちんとレベルアップすることを確かめてみるようなことが外部テストとなります。テストファーストとテストラストさらにテストは、テストファーストとテストラストという観点でも整理できます。テストファーストテストを最初に書いて、そのテストを満たすようにコードを実装する開発手法をテストファーストと言います。著書『テスト駆動開発入門』や本誌るびまの連載「スはスペックのス」などを参照ください。テストファーストでのテストは、テストを記述してから実際に検証するまでを短いサイクルで回す単体テストや結合テスト段階で用いられるのが自然です。テストファーストで行うことも可能ですが、テストを記述してから実際に検証するまでのサイクルがどうしても長くなりますので、「仕様を明確にすること」と「仕様を実現すること」の因果関係が遠くなってしまい、あまり向いていません。近年注目を集めている開発手法である「継続的インテグレーション」では「自動テスト」を実施しますが、これには「仕様が満たされていることをテストするためのテストコード」が存在していることが前提になります。テストファーストを実施していると、その前提を自然と満たすことができます。テストラスト出来上がったシステムがきちんと動作することを確認する、というのがテストの基本です。いう本来のテスト方法も脈々と流れています。記述することが多いようです3。仕様書からテストすべき項目を洗い出し、スプレッドシートに列挙します。テスト実施後にはテスト結果をスプレッドシートに追記し、保存し管理します。列挙し、テストを実施し、テスト結果の管理を行うという方式は、脈々と行われています。開発者がテストするのではない第三者テストでは、それが主流でしょう。それはそれで磨き抜かれた方法ではあります。テストコードが無くても人間がテスト項目に基づいて動作チェックするので、いろいろな観点でテストができます。時間がかかるのが宿命です。テストラストでは、単体テスト、結合テスト、総合テストのすべての段階をカバーできますが、単体テストを網羅して記述するのには冗長でかつ膨大になるので向いていません。逆に出荷テストや受け入れテストはテストラストで行われるのが普通ですので、「テストファーストだけ」または「テストラストだけ」ですべてのテストを網羅するのではなく、適材適所で使い分けるのが良いでしょう。テストツールの進化・変遷テストの本質は変わらなくても、ツールは次々と変遷してゆきます。使われるテストツールの進化・変遷を見ていきます。流行とともに普及しています。よっても仕様記述や評価が可能となる世界が開けました。実装者だけの「内部テスト」「テストファースト」の枠から、実装者以外の「外部テスト」「テストラスト」へ枠の拡がりの突破口を開きました。周りでのテストツールの変遷を見てみましょう。ないと時代遅れ8となってしまうという、何とも進化の早い世界であることが分かると思います。テストツールもベタからメタへソフトウェアで注目されるトピックは時代とともに変わり、OSからミドルウェアへ、そしてアプリケーションへと移ってきました。利用した振る舞いの記述」へ進化しています。その流れを言葉で表現してみると、「ベタからメタへ」となります。いうファイルにテストを記述します9。いうファイルにテストを記述します。別の書き方にしたもので、その「書き方」によってテストの記述がわかりやすくなりました。引用させていただきます。特徴である、システムの振る舞いを記述するための自然言語に近い書式のこと。段階のファイルに分割して記述します。ファイルのサンプルを内容を一部改変して引用すると、次の記述となります。ログイン機能などで自分の情報を識別したい。メッセージなどを「自分のもの」として区別したいからだ。さん"と表示されていることテストの記述に自然な日本語が使えるというのは、実にうれしいところです。わかり易く図解してみましょう。Cucumber継続的インテグレーションツールの普及とエンドツーエンドテストの需要の高まり先ほども述べましたが、近年では「継続的インテグレーション」による迅速で効率的な開発に関心が高まり、テストの自動化を実現する継続的インテグレーションのためのツールも普及してきています。実践している場合は、作りためたテストを整理してまとめて動かせばボトムアップテストとなりますので、継続的インテグレーションツールによるテスト自動化は自然の流れです。使うことで、ボトムアップで行う単体テスト・結合テスト段階を越えて、トップダウンで行う総合テストを自動化することができます。ステップ内で使うことにより、これまで自動化が難しく手動での目視確認となっていたエンドツーエンドテストを自動化することができます。エンドツーエンドテストの自動化が完成すれば、リグレッションテストの迅速化・省力化に寄与できます。これは開発コストの相当な割合を占めるテストを合理化する有利な手段となります。まとめると、継続的インテグレーションツールでの自動テストのニーズは、単体テスト・結合テスト段階から総合テストへと範囲が拡がってきています。その流れを言葉で表現してみると、やはり「ベタからメタへ」となります。段階で振る舞いをテストでき、コードの世界とは別次元の「テスト記述の世界」が展開できるというのが画期的でした。「テストを日本語で記述できる」という点で、第三者にもわかりやすいというのも大きなメリットです。ボトムアップで断片から全体が構成されるというスタイルです。ありきで出発することもできるので、トップダウンでの機能テスト構成の記述が可能となったのです。このボトムアップかトップダウンかという違いは実はシステム全体のテスト・評価という観点から見るとかなりの違いであり、トップダウンでの機能テストが記述できるというのはテスト自動化への大きな進歩です。普及していないようです。具体的な要素ツールの進化が激しく、バージョンが異なるとすぐに動作しなくなる。ファイルは良いとして、実際のプログラムレベルを記述するステップファイルの実装にはそれなりのスキルが要求され、スケジュールが確保されていないと負荷が高い。正規表現を扱う箇所が敷居を高くしている。重にテストすることになり、結構な手間がかかる。orz」というのが実態なのではないでしょうか。改善案として提案されました。システムでのエンドツーエンドのテストを自動化する際に利用できます。問題点を改善して実装されている筋の良さで、今後の普及が期待されています。