-
Notifications
You must be signed in to change notification settings - Fork 2
/
02.tex
59 lines (44 loc) · 5.55 KB
/
02.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
\section{サーバの構成管理とテスト手法}
本論文で提案するテストフレームワークは,構成管理ツールによりサーバ構成を記述したコードのテストをいかに効率よく行うか,という観点から出発している.そこで代表的な構成管理ツールを例に,ツールと言語の特徴,テスト手法ならびに従来手法の問題点について言及する.
\subsection{CFEngineからChefへ}
第1章で触れたCFEngineは1993年に登場した.2005年にはCFEngineに影響を受け,より抽象度と拡張性を高める形で発展させたPuppet\cite{puppet}が登場,2009年にはPuppetから影響を受け,コードのプログラマブルな側面を強めたChef\cite{chef}が登場している.
\subsection{ChefからTest-Driven Infrastructureへ}
CFEngine,Puppetは独自のドメイン固有言語でサーバの構成を記述するが,Chefは実装言語と同じ言語を利用したドメイン固有言語,すなわちRuby\cite{ruby}という汎用プログラミング言語で記述する.その特性ゆえ,Chefはシステム管理者よりも開発者に強く訴求し,Amazon EC2\cite{ec2}の様な開発者自身がサーバ構築・運用を行える環境の普及とともに広まりを見せている.しかし,汎用プログラミング言語であるが故に,システムが複雑になるにともない,それを記述するコードも複雑になる.そこでサーバ構成を記述したコードに対し,アジャイル開発におけるテスト駆動開発のプロセスを適用する事で,効率よくコードを記述することができる,といった考えが生まれる.Test-Driven Infrastuctureという概念はChefコミュニティ周辺で発生したものであるが,それは偶然ではなく,このようなChefが持つ言語特性ゆえである.
\subsection{Test-Driven Infrastructureにおけるテスト手法の分類}
Test-Driven Infrastructureにおけるテストの種類は,テスト駆動開発における以下の三つに分類できる.
\begin{enumerate}
\item 単体テスト
\item 結合テスト
\item 受け入れテスト
\end{enumerate}
単体テストは構成管理ツールにおける``モジュール''に対するテストで,実際にコードをサーバに適用する前の段階で行うテストである.結合テストはコードをサーバに適用した後に行うテストで,コードが期待通りにサーバの設定を行ったかどうかをテストする.受け入れテストもコードをサーバに適用した後に行うテストだが,結合テストがサーバ内部の状態をテストするホワイトボックステストであるのに対し,受け入れテストはサーバの外から見た振る舞いをテストするブラックボックステストであるという違いがある.
\subsection{従来テスト手法の問題点}
(1)に分類される単体テストツールとしては,ChefにはChefSpec,Puppetにはrspec-puppetというツールが存在する.その名が示すとおり,それぞれChefとPuppet専用のツールであり,サーバに対してコードを適用して設定を行うことなく,コードの整合性等のテストを行う.しかし,実際にコードをサーバに適用した結果をテストすることはできないため,単体テストツールだけではサーバのテスト手法としては不十分である.
(2)に分類される結合テストツールとしては,minitest-chef-handler,Test Kitchen,rspec-systemが存在する.この内minitest-chef-handlerはテストの実装がChefに依存しており,テストの実行にChefのインストールが必要である.Test Kitchenやrspec-systemは,テスト用VMの作成,テスト用VMへの構成管理ツールの適用,テストの実行をトータルで行う統合テストスイートであるが,Test Kitchenは構成管理ツールとしてChefを利用することが前提となっている.また,Test Kitchen,rspec-systemともに,ツール標準のテスト機構は汎用性に乏しく,OSやディストリビューション毎の違いを意識したテストコードを書く必要がある.
(3)に分類される受け入れテストツールとしてはcucumber-chef,leibnizが存在するが,これらはChefに依存したツールであり,他の構成管理ツールとともに利用することができない.
\begin{table}[htb]
\begin{center}
\caption{テストツール比較表\label{tab:comparison}}
\begin{tabular}{c|ccc}
\hline
\hline
ツール名 & テスト種別 & ツール独立性 & OS汎用性 \\
\hline
ChefSpec & 単体 & × & ○ \\
\hline
rspec-puppet & 単体 & × & ○ \\
\hline
minitest-chef-handler & 結合 & × & ○ \\
\hline
Test Kitchen & 結合 & × & × \\
\hline
rspec-system & 結合 & ○ & × \\
\hline
Cucumber-Chef & 受入 & × & ○ \\
\hline
leibniz & 受入 & × & ○ \\
\hline
\end{tabular}
\end{center}
\end{table}
表\ref{tab:comparison}に各テストツールの比較を示す.これにより,従来テスト手法では,どのテスト種別においても,構成管理ツールからの独立性とOS・ディストリビューションの汎用性双方を満たすものが存在しないことがわかる.