\subsubsection{Verifikation}
\label{ssub:verifikation}

Wie auch in der Softwareentwicklung müssen Konfigurationssysteme getestet
werden. Dies gestaltet sich oft als schwierig, weil nicht immer eine exakte
Kopie des aktuellen Produktionssystem zur Verfügung steht. Mit steigender
Komplexität steigt der Aufwand, geschriebene Cookbooks manuell zu testen. Im
Folgenden werden verschiedene Möglichkeiten aufgeführt, wie dies automatisiert
werden kann.

Die erste und einfachste Methode ist der Befehl:

\shellcmd{knife cookbook test [COOKBOOKS...]}

Das Kommandozeilenprogramm \emph{knife} ist Teil von Chef. Es ist das primäre
Verwaltungsprogramm für Adminstratoren.  Der Unterbefehl \emph{cookbook test}
überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderes da Ruby eine
dynamische Programmiersprache ist. Ein anderes Programm ist foodcritic. Es führt
eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint} oder
\href{http://perl-critic.stacka.to/}{Perl::Critic} auf der eigenen Codebasis
durch. Dabei wird der Rubycode gegen einen Regelsatz getestet, um so häufige
Programmierfehler zu erkennen oder um Codingstandards innerhalb eines Projekts
einzuhalten. Dieser Regelsatz kann durch eigene Regeln erweitern werden.

\textbf{Chefspec}
\label{chefspec}

Chefspec baut auf das, in Ruby verbreitete, Testframework
\href{http://rspec.info/}{RSpec} auf. Rspec ist ein Testframework, welches auf
\href{http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/}{Behavior Driven
Development} (kurz BDD) basiert. Hierbei dokumentieren sich Testcases selbst
durch Einfügen von Beschreibungen. RSpec kann Sätze aus diesen Beschreibungen
bilden und so im Falle eines fehlgeschlagen Tests schnell darüber Auskunft
geben, was der Test getestet hat und aus welchen Grund dieser fehlgeschlagen
ist. Chefspec erweitert dabei RSpec um die Funktion, Cookbooks zu laden und
stellt spezielle Matcher (RSpec-Terminologie für Assertions) bereit, um diese zu
testen.  Wie bereits in Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt,
gibt es zwei Phasen bei der Ausführung von Chef. Bei Chefspec wird der
Provisionierungsprozess nur bis zur Convergingphase durchlaufen. Die eigenen
Tests überprüfen nur die erzeugten \emph{Resources}. Dies hat den Vorteil, das
Tests sehr schnell durchlaufen werden, da keine Änderungen an einem System
vorgenommen werden müssen. Dies hat Vorteile beim Entwickeln, weil man auf diese
Weise schnell Feedback bekommt. Das Zusammenspiel mehrerer Cookbooks lässt sich
dadurch gut testen. Außerdem ermöglicht es, verschiedene
Konfigurationen/Betriebssysteme durchzutesten, ohne das diese (zeit)aufwendig
aufgesetzt werden müssen. Da Chefspec allerdings zu keinen Zeitpunkt Code auf
dem System ausführt, sind weitere Integrationstest unerlässlich.

Der folgende Test wurde aus dem selbst geschriebenen NTP-Cookbook
(\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.

\begin{lstlisting}[language=Ruby]
require_relative '../spec_helper'

describe 'ntp::default' do
  let(:chef_run) do
    ChefSpec::Runner.new do |node|
      node.set["ntp"]["subnets"] = ["::1", "127.0.0.1", "172.28.128.0 mask 255.255.255.0 nomodify notrap nopeer"]
    end.converge(described_recipe)
  end

  it "should setup ntp" do
    chef_run.should install_package("ntp")
    chef_run.should render_file("/etc/ntp.conf").with_content("172.28.128.0")
  end
end
\end{lstlisting}

Im \emph{chef\_run}-Block wird der fiktiven Node Attribute zugewiesen und das zu
testende Cookbook ausgeführt. Das Ergebnis wird in diesem Beispiel in dem Objekt
\emph{chef\_run} gespeichert. Gegen dieses Objekt wird getestet, ob bestimmte
\emph{Resources} korrekt initialisiert wurden. In diesem Fall wird überprüft, ob
das Paket \emph{ntp} installiert werden soll und ob das Subnetz in dem Template
in der Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.

Die Tests werden mit dem Befehl \emph{rspec} ausgeführt. Wenn keine weiteren Argumente
angegeben sind, führt dieses Programm alle Dateien unterhalb des Ordners \emph{spec}
aus, dessen Dateinamen auf \emph{\_spec.rb} enden.

Um alle drei oben genannten Testmethoden gleichzeitig ausführen zu lassen, wurde
ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das, in
Ruby geschriebene Äquivalent, zu Make, welches ein verbreitetes Buildprogramm
auf Unix-Ähnlichen Plattformen ist. Die Tests werden durch den Task \emph{test}
ausgeführt:

\shellcmd{rake test}

Dieser muss innerhalb Projektverzeichnises aufgerufen werden.

\textbf{Minitest-Handler}
\label{minitest_handler}

\href{https://github.com/btm/minitest-handler}{Minitest-Handler} hingegen wird
nach jedem Provisionierungsdurchgang ausgeführt. Im Gegensatz zu Chefspec nutzt
es das Minitest-Framework, welches schon mit Ruby mitgeliefert wird. Allerdings
kann man durch einbinden, der Zeile:

\begin{lstlisting}
require "minitest/spec"
\end{lstlisting}

eine Syntax benutzen, die RSpec sehr ähnliche ist. Um Minitest-Handler zu
nutzen, muss das Recipe aus \emph{Minitest-Handler-Cookbook} als erstes Recipe
in der node geladen werden. Minitest-Handler durchsucht beim Durchlauf in jedem
anderen Cookbook, in den Unterordnern in \emph{files/} nach dem Verzeichnis
\emph{test} und lädt alle Tests aus diesem Verzeichnis. Über die
Beschreibungszeile:

\begin{lstlisting}[language=Ruby]
describe_recipe "ntp::default" do #
#...
end
\end{lstlisting}

wird angeben, für welches Recipe der Test gedacht ist (In diesem Fall das
Defaultrecipe aus dem NTP-Cookbook). Wenn das entsprechende Recipe von der Node
ausgeführt wird, wird der dazugehörige Test nach dem Provisionierungsdurchlauf
ebenfalls ausgeführt. Minitest-Handler erweitert RSpec um nützliche Methoden, um
den Status des Systems zu überprüfen. Nachfolgend ein Beispiel aus dem Bind-Cookbook,
welches in Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde:

\begin{lstlisting}[language=Ruby]
describe_recipe 'bind::default' do
  it "starts the named daemon" do
    service("bind9").must_be_running
  end
  it "should resolve dns" do
    assert_sh("dig localhost @localhost")
  end
end
\end{lstlisting}

Die Methode \emph{assert\_sh} überprüft den Exitstatus eines Befehls und schlägt
fehl, wenn dieser ungleich Null ist, während die \emph{service}-Methode den
Status eines Systemdienst sicherstellt.  Weitere Testmedhoden sind zum Beispiel
das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints. Viele
Fehler werden in der Regel schon von den Provider erkannt und festgestellt.
Minitest-Handler kann dies Erweitern um protokollspezifische Tests durchzuführen
oder das Testen von Funktionalität bestimmter Dienste.

TODO Resume und Ausblick

% vim: set spell spelllang=de_de