 |
||||||||||||||||
|
||||||||||||||||
| 1 2 3 4 次のページ | ||||||||||||||||
|
||||||||||||||||
| テストの自動化 | ||||||||||||||||
|
近年のシステム開発では図1に示すように自動化されたテストを取り込み、継続的インテグレーションを実現した開発スタイルが提唱されています。  図1：テストの自動化 テストの自動化を導入することで、ソフトウェア開発で最も恐れるべき事象の1つであるデグレードを回避することができるため、積極的にコードを整理（リファクタリング）することができるようにもなります。 またテストの自動化は、先進的なアジャイル開発ではもちろんのこと、従来のウォーターフォール型開発プロセスにも有効的な適用が可能であるため、近年急速に一般化しつつあります。そしてRuby on Rails（以下、Rails）にはテストの自動化を実践するためのサポートが含まれています。 |
||||||||||||||||
| Railsのテストサポート | ||||||||||||||||
|
それではRailsではどのようにテストの自動化がサポートされているのでしょうか。 |
||||||||||||||||
| Railsのテスティングフレームワークの構成 | ||||||||||||||||
|
RailsではRubyに標準で付属するテスティングフレームワークである「Test::Unit」が拡張されて提供されます。「Test::Unit」はJUnitに代表されるxUnitを意識したつくりになっており、それらを利用したことがある方にはとっつきやすくできています。 テストに関するファイルはtestフォルダにまとまっています（図2）。  図2：フォルダ構成
表1：各フォルダの用途 テストのプログラムが書きやすいようにはじめからモデルとコントローラのテストを分けて考えていたり、DB（データベース）の初期化やモックの機能が搭載されている点からも徹底したテストの自動化を前提に構成されていることがわかると思います。 |
||||||||||||||||
| 環境モードとテスト | ||||||||||||||||
|
前回までは意識することなく進めてきましたが、Railsには「環境モード」という考え方があります。環境モードには表2にあげた3つのモードがあらかじめ準備されています。
表2：環境モード一覧 環境モードはサーバ起動時に指定することができます。各モードでは想定された状況に挙動が最適化されているほか、モード別にDBを定義できるため各々のデータを干渉させずに開発を進めることが可能です。 テスト時のモードであるtestモードのDBには、テスト実行前にdevelopmentモードのDBからスキーマ情報を簡単にインポートできます。この機構によって開発中にdevelopmentモードのデータを汚すことなく、またスキーマの同期が取れた状態で思う存分テストを実施することができます。 |
||||||||||||||||
| rakeを用いた継続的インテグレーション | ||||||||||||||||
|
RailsのテストはRadRailsなどのIDE（統合開発環境）から実行するほかにも、Rubyのバッチ的な位置づけである「rake」経由でも実施開始することができます。 rakeでは定義次第でSubversionやCVSなどのバージョン管理システムからソースコードをチェックアウトしてくることも可能ですので、cronやatなどのタスクスケジューラで定期的にrakeを流すようにすれば、継続的インテグレーションのベースを構築することができます。 |
||||||||||||||||
|
1 2 3 4 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
