Huch, das kommt davon, wenn man von unterwegs schreibt.
Klassen- und Methoden, die zum Contract gehören, der wird in der Tat abgesprochen bevor die erste Code-Zeile geschrieben ist oder auch der 1. Test. Dazu gibts zu jedem Sprint-Beginn ein Meeting, in dem nicht nur die Entwickler, sondern auch die QA-Nasen und die Product Owner sitzen.
Das kann nicht immer gehalten werden, aber meistens.
"Nur" Namen ist ja relativ einfach - wenn ich eine Methode von "_begruessung()" zu "_begruessungLokalisiert()" ändern will, ist das im besten Fall eine Textersetzung, mit Pech kommt noch ein Parameter dazu. Der Contract einer Schnittstelle an sich sollte schon halten.
Cucumber unterstützt ja streng genommen kein Test-driven development, sondern behaviour-driven development. Das ist gut z.B. für GUI-Entwicklung, denn es kommt in der Interaktion mit dem Anwender primär auf das Verhalten an, dass Rückmeldungen ankommen, dass der Anwender Zeit hat, sie zu lesen (ich hasse solche Flyouts, die links unten aufpoppen und wieder verschwinden, bevor ich 3 Worte gelesen habe), dass das Programm aus der gefühlten Sicht des Anwenders "tut was es soll".
Im Abrechnungsbereich, bei Schnittstellen zu Fremdsystemen oder auch in der Regelungstechnik kommt es auf Exaktheit an, und ganz oft hast du da ja gar keine Interaktion mit einem Anwender. Da ist ein Test spitz zu erfüllen.