b2aat6n

Listing 15
Die öffentliche Schnittstelle
verwenden.
[Test]
public void FIFO_verschachtelt() {
sut.Enqueue(1);
Assert.That(sut.Dequeue(),
Is.EqualTo(1));
sut.Enqueue(2);
Assert.That(sut.Dequeue(),
Is.EqualTo(2));
sut.Enqueue(3);
sut.Enqueue(4);
Assert.That(sut.Dequeue(),
Is.EqualTo(3));
Assert.That(sut.Dequeue(),
Is.EqualTo(4));
}
von automatisierten Tests. Die Skizze einer
Warteschlange im Vorher-Nachher-Vergleich
war schnell erstellt, siehe Abbildung 4.
Doch bis das Umdrehen der Zeiger korrekt
lief, mussten die Tests einige Male
durchlaufen. Ich habe wirklich keine Ahnung,
wie man so etwas ohne automatisierte
Tests hinkriegen will. Na ja, ich habe
irgendwann auch mal ohne automatisierte
Tests entwickelt. Aber das ist glücklicherweise
schon lange her. Listing 17 zeigt den
Test für die Umkehr der Reihenfolge.
Bei der Implementierung habe ich mit
zwei Zeigern gearbeitet, die jeweils auf das
aktuelle in Arbeit befindliche Element (current)
sowie das nächste Element (next) verweisen.
Da die Elemente jeweils mit Prev
auf ihren Vorgänger verweisen, wird die
Warteschlange von hinten nach vorne abgearbeitet.
Daher ist jeweils das Element, welches
im zurückliegenden Schleifendurch-
[Abb. 4] Die Reihenfolge der
Elemente umkehren.
Listing 16
lauf bearbeitet wurde, das nächste Element
im Sinne der normalenVorwärts-Reihenfolge.
Am Ende sind noch enqueue und dequeue
zu vertauschen, siehe Listing 18.
Die Methode habe ich über die öffentliche
Schnittstelle getestet. Man hätte sicherlich
auch hier die interne Repräsentation
heranziehen können, ich glaube aber, dass
die Tests dadurch schlecht lesbar geworden
wären. Daher wird die Beispielwarteschlange
mit enqueue aufgebaut, anschließend
[Abb. 3] Prev-Zeiger bei der Queue.
Die Queue implementieren.
public class Queue
{
internal Element enqueue;
internal Element dequeue;
public void Enqueue(TElement element) {
var newElement = new
Element {Data = element};
if (enqueue != null) {
enqueue.Prev = newElement;
}
enqueue = newElement;
if (dequeue == null) {
dequeue = newElement;
}
}
public TElement Dequeue() {
if (dequeue == null) {
throw new
InvalidOperationException();
}
var result = dequeue.Data;
dequeue = dequeue.Prev;
if (dequeue == null) {
enqueue = null;
}
return result;
}
}
Listing 17
umgedreht und dann mit dequeue überprüft,
ob die Elemente in der richtigen, umgekehrten
Reihenfolge geliefert werden.
Fazit
LÖSUNG
Die Umkehr der Reihenfolge
testen.
[TestFixture]
public class ReverseTests {
private Queue sut;
[SetUp]
public void Setup() {
sut = new Queue();
}
[Test]
public void
Eine_Queue_mit_drei_Elementen_kann
_umgekehrt_werden() {
sut.Enqueue(1);
sut.Enqueue(2);
sut.Enqueue(3);
sut.Reverse();
Assert.That(sut.Dequeue(),
Is.EqualTo(3));
Assert.That(sut.Dequeue(),
Is.EqualTo(2));
Assert.That(sut.Dequeue(),
Is.EqualTo(1));
}
}
Listing 18
Die Reihenfolge umkehren.
public void Reverse() {
var current = dequeue;
Element next = null;
while(current != null) {
var prev = current.Prev;
current.Prev = next;
next = current;
current = prev;
}
var dummy = enqueue;
enqueue = dequeue;
dequeue = dummy;
}
Bei der testgetriebenen Entwicklung hat
sich für mich bestätigt, wie nützlich die
Planung auf Papier ist. Mir ist deutlich geworden,
dass die Auswahl der Reihenfolge
der Tests bei TDD wichtig ist. Daher sollte
man in schwierigeren Szenarien immer
erst Testfälle sammeln und diese dann in
eine sinnvolle Reihenfolge bringen, bevor
man mit dem ersten Test beginnt. [ml]
www.dotnetpro.de dotnetpro.dojos.2011 43