Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.
In dem Fall würde man aber erst die Tests korrigieren und danach, wenn die dann fehlschlagen, den eigentlichen Code.
Leider fallen viele Anwender von TDD in die Rot-Grün-Falle: Der Code wird solange angepasst, bis alle Tests grün sind. Dann geht es schon weiter zum nächsten Bug/Feature/Test. Der TDD-Zyklus ist damit aber noch gar nicht abgeschlossen, denn er besteht aus drei Schritten:
write the test - write code to make the test green - refactor the code to make it clean. Der letzte Schritt wird leider viel zu oft übersprungen, da er leider sehr zeit-intensiv ist und einen guten Überblick über das Gesamtprojekt erfordert. Übrigens: Das Postulat
schreibe nie mehr Code als nötig ist, um den Test grün zu machen ist hierzu kein Widerspruch. Wir schreiben ja nicht mehr Code, sondern ändern lediglich den vorhandenen. Dabei nutzen wir den grünen Test als Hinweis, daß wir beim Refactoring nichts kaputt gemacht haben.