Im fehlerhaften Projekt wissen wir von einem Fehler. Das bedeutet, dass wir bereits einen Soll-Zustand kennen, den wir mit der bisherigen Implementierung nicht erreichen. Schauen wir uns das Hauptprogramm an:

int main( void )
{
  Stack stack(10);
 
  stack.Push( 1 );
  stack.Push( 2 );
  stack.Push( 3 );
 
  for( unsigned int value; stack.Pop( value ); )
    printf( "Wert: %d\n", value );
 
  return 0;
}

Das Programm stürzt ab. Wir haben also bereits einen ersten Testfall, der zunächst fehlschlagen sollte und nach der Korrektur keinen Fehler melden sollte.

Es macht in der Regel keinen Sinn, getter wie getPosition(), getBuffer() oder getSize() zu testen. Dennoch erlauben sie Zugriff auf Interna der zu testenden Klasse. Nachdem wir den Stack angelegt mit einer Größe von 10 Elementen haben, muss getSize() den Wert 10 zurückliefern. Die kann man abtesten. Ebenso muss sich getPosition() vergrößern, wenn ein Wert hinzugefügt wird und verkleinern, wenn ein Wert vom Stack weggenommen wird.

Bei einfachen Gettern und Settern, die nur eine Variable lesen oder setzen, ist ein Test in der Regel überflüssig. Funktionen, die jedoch den Zustand des Objektes aufgrund einer noch so einfachen Berechnung gegengetestet werden.

Diese Implementation hat zwei Schwachstellen:

• Was passiert, wenn man einen Wert abruft, obwohl kein Wert auf dem Stack liegt
  Dieser Fall verursacht vermutlich auch den Absturz im Projekt.
• Was passiert, wenn man mehr Werte auf den Stack legt, als der Stack an Speicher reserviert hat?

Der zweite Fall tritt in unserem Hauptprogramm gar nicht auf. Aber der Stack wird vielleicht nicht nur einmalig verwendet, bzw. eine andere Daten benötigen mehr Einträge auf dem Stack.