b2aat6n

Stack und Queue implementieren
Der Nächste bitte!
Immer hübsch der Reihe nach: Das gilt nicht nur im Wartezimmer, sondern auch im Stack und in der Queue der
Informatiker. Und wer sich das Entwicklerleben vereinfachen will, sollte auch bei ihrer Implementierung
die richtige Reihenfolge einhalten: Erst planen, dann Tests entwickeln, dann implementieren.
A
ls Entwickler nehmen wir
Stack und Queue, wie viele
andere Datenstrukturen, als
selbstverständlich hin, sind
sie doch im .NET Framework enthalten.
Weil ihre Funktionsweise so einfach ist, besteht
sicherlich die Versuchung, direkt mit
der Implementierung zu beginnen. Doch
schon kommen die ersten Fragen um die
Ecke: Wie soll der erste Test aussehen? Wie
testet man einen Stack überhaupt, das
heißt, kann man Push isoliert testen? Oder
kann man Push nur testen, indem man Pop
ebenfalls testet?
Bevor Sie versuchen, diese Fragen zu beantworten,
sollten Sie den Konsolendeckel
besser erst mal schließen und zu einem
Stück Papier greifen. Denn die zentrale Frage
vor dem ersten Test lautet, wie denn die
interne Repräsentation des Stacks überhaupt
aussieht. Dies mit Papier und Bleistift
zu planen ist einfacher, als es einfach
so im Kopf zu tun. Dabei übersieht man
schnell mal ein Detail.
Ein Stack muss in der Lage sein, jeweils
das oberste Element zu liefern. Das ist die
Aufgabe der Pop-Methode. Nachdem das
oberste Element geliefert wurde, muss der
Stack beim nächsten Mal das nächste Element
liefern, das also unmittelbar auf das
oberste folgt. Daraus ergibt sich die Notwendigkeit,
innerhalb des Stacks jeweils zu
wissen, welches das oberste Element ist.
Ferner muss zu jedem Element bekannt
sein, welches das nächste Element ist. So ergibt
sich eine ganz einfache interne Datenstruktur
für den Stack, siehe Abbildung 1.
Hat man diese Datenstruktur erst einmal
aufgemalt, ist es ein Leichtes, sie in Code
zu übersetzen. Aber Achtung, den Test
nicht vergessen! Bei einem Stack bietet es
sich an, zwei unterschiedliche Zustände zu
betrachten:
❚ einen leeren Stack,
❚ einen nicht leeren Stack.
In solchen Fällen erstelle ich für die unterschiedlichen
Szenarien gerne getrennte
[Abb. 1] top- und
next-Zeiger im
Testklassen. Dann kann nämlich das Setup
des Tests dafür sorgen, dass das Szenario
bereitgestellt wird. Die Testklasse, welche
sich mit einem leeren Stack befasst, instanziert
einfach einen neuen Stack. In der Testklasse
zum Szenario „nicht leerer Stack“
wird der Stack im Setup gleich mit ein paar
Werten befüllt. So können sich die Tests jeweils
auf das konkrete Szenario beziehen.
Doch wie sieht nun der erste Test aus?
Ich habe mich entschieden, den ersten Test
zu einem leeren Stack zu erstellen. Es erscheint
mir nicht sinnvoll, bei dem Szenario
eines nicht leeren Stacks zu beginnen,
weil dann vermutlich für den ersten Test
bereits sehr viel Funktionalität implementiert
werden muss. Ich möchte lieber in
kleinen Schritten vorgehen, um sicher zu
sein, dass ich wirklich nur gerade so viel
Code schreibe, dass ein weiterer Test erfolgreich
verläuft.
Für den ersten Test zu einem leeren Stack
überlege ich mir, wie die interne Repräsentation
eines leeren Stacks aussehen soll, und
komme zu dem Schluss, dass der Zeiger, der
auf das erste Element verweist, null sein soll.
Listing 1 zeigt den ersten Test. In der Setup-
Methode der Testklasse wird ein leerer Stack
für int-Elemente instanziert. Der erste Test
prüft, ob dann der top-Zeiger gleich null ist.
Nun wird vielleicht dem einen oder anderen
der Einwand im Kopf herumkreisen,
dass damit ja erstens die Sichtbarkeit der
internen Repräsentation nach außen getragen
wird und zweitens Interna getestet
werden. Zur Sichtbarkeit sei gesagt, dass
Listing 1
LÖSUNG
Einen leeren Stack testen.
[TestFixture]
public class Ein_leerer_Stack {
private Stack sut;
[SetUp]
public void Setup() {
sut = new Stack();
}
[Test]
public void Hat_kein_top_Element() {
Assert.That(sut.top, Is.Null);
}
}
ich das Feld top auf internal setze. Damit
ist es zunächst nur innerhalb der Assembly
sichtbar, in der die Stack-Implementierung
liegt. Durch ein Attribut in der Datei AssemblyInfo.cs
wird die Sichtbarkeit dann
dosiert erweitert auf die Testassembly. Das
Attribut sieht wie folgt aus:
[assembly:
InternalsVisibleTo("stack.tests")]
Damit kann nun auch aus der Testassembly
auf die Interna zugegriffen werden.
Und schon sind wir beim zweiten Einwand,
dass nun diese Interna im Test verwendet
werden. Das halte ich für vernachlässigbar.
Sicher ist es erstrebenswert, Tests
so zu schreiben, dass sie möglichst wenige
Abhängigkeiten zu den Interna der Klasse
haben. Denn wenn nur über die öffentliche
Schnittstelle getestet wird, sind die Tests
www.dotnetpro.de dotnetpro.dojos.2011 39
Stack.
Listing 2
Datenstruktur für die Stack-
Elemente.
internal class Element {
public TData Data { get; set; }
public Element Next{get; set;}
}