Du erbst einen Service ohne Tests und musst seine Kernlogik ändern. Wie gehst du das an?

Nagel das aktuelle Verhalten fest, bevor du es änderst. Schreib Characterization Tests an einer stabilen Grenze, füttere echte Eingaben und assertiere, was der Code heute tut, Bugs inklusive, damit du ein Netz hast, das Änderungen erkennt. Dann refactore in kleinen Schritten mit grünen Tests und zieh die Logik, die du anfassen musst, in etwas Testbares heraus. Erst wenn die Naht existiert, änderst du Verhalten, und jede Änderung bekommt ihren eigenen Test.

Ich ändere keine Logik, die ich nicht verifizieren kann, Schritt eins ist also ein Netz. Ich schreibe Characterization Tests an der höchsten stabilen Grenze, meist dem HTTP-Handler oder einem Service-Einstiegspunkt, und ich assertiere, was der Code gerade tut, inklusive Dingen, die ich für Bugs halte. Der Punkt ist nicht Korrektheit, sondern Änderungen zu erkennen. Wenn ich Produktionszugriff habe, nehme ich ein paar hundert echte Request-Response-Paare auf, denn handgebaute Eingaben verfehlen die schrägen Fälle, und die schrägen Fälle sind es, die kaputtgehen. Dann refactore ich in kleinen Schritten mit durchgehend grünen Tests und ziehe die Logik, die ich wirklich anfassen muss, in eine Funktion, die ich direkt aufrufen kann. Erst dann ändere ich Verhalten, und jede Änderung kommt mit einem echten Test plus einer Entscheidung darüber, ob das alte Verhalten Absicht war. Bei einem Legacy-Pricing-Service habe ich genau das gemacht, und der aufgenommene Traffic hat zwei Rundungspfade offengelegt, die sich widersprochen haben und von denen niemand wusste. Genau so etwas findest du mit einem Netz und zerstörst du ohne.