Die Zeit, in der Testcode zum neuen Burggraben wird
(saewitz.com)-
Das Paradox des Erfolgs: Je stärker ein Projekt wächst, desto mehr schleppt es die Last der Abwärtskompatibilität und einer riesigen Codebasis (The Ship of Theseus) mit sich. Ein Wettbewerber kann dagegen die API-Spezifikationen, die Dokumentation und den Testcode eines bestehenden Projekts von einer KI auswerten lassen und daraus in kürzester Zeit eine „leichtere und modernere Version“ extrahieren, die nur den Kernwert übernimmt.
-
Fallbeispiel Cloudflare vs. Vercel: Cloudflare nutzte die über Jahre aufgebaute umfangreiche Dokumentation und Test-Suite von Next.js bei Vercel, um in nur einer Woche eine schlanke, auf Vite basierende Next.js-kompatible Runtime zu entwickeln. (Wird inzwischen auch auf der US-Regierungswebsite cio.gov eingesetzt)
-
Testcode als Vermögenswert: Früher war vor allem der Code selbst entscheidend, heute sind der „Softwarevertrag“ (Contract) und die „Testfälle“ die teuersten Assets. Sie offenzulegen, kommt dem Bereitstellen eines präzisen Bauplans gleich, mit dem ein Wettbewerber meinen Service praktisch eins zu eins kopieren kann.
-
Die Weitsicht von SQLite: SQLite veröffentlicht zwar den Code, hält aber die gewaltige Test-Suite geheim, die mit 92 Millionen Zeilen dem 590-Fachen des Quellcodes entspricht. Genau das wurde zu ihrem „Burggraben“, der ihnen ermöglicht, das Open-Source-Ökosystem aufrechtzuerhalten und gleichzeitig kommerzielle Verteidigungsfähigkeit zu besitzen.
-
Fazit: Kommerzielle Open-Source-Unternehmen im KI-Zeitalter stehen an einem Punkt, an dem sie eine Entscheidung zwischen „vollständigem Altruismus“ (Open Source) und „geschäftlichem Überleben“ treffen müssen. Viele Projekte werden wohl wie SQLite dazu übergehen, ihren Testcode nicht mehr öffentlich zu machen und so eigenständige technische Eintrittsbarrieren aufzubauen.
19 Kommentare
Aus dieser Perspektive könnten vielleicht Dokumente wie ADR (Architecture Decision Records) oder CIR (Change Intent Records) eines Tages sogar höher geschätzt werden als der Code selbst.
Ziemlich beeindruckend. Obwohl der Text kurz ist, leuchtet es sofort ein. Die Sicherheit des Testcodes könnte sogar wichtiger sein als die des Quellcodes.
Für mich klingt das so, als dürfte man E2E-Tests auf keinen Fall weglassen. Mich würde interessieren, wie andere das sehen.
Ich bin überhaupt kein Entwickler ... aber aus Spaß am Ausprobieren von AI lasse ich ein bisschen coden, und obwohl ich es gar nicht verlangt habe, hat sie jede Menge Testcode erzeugt und gespeichert — jetzt verstehe ich also, warum.
Als ich gefragt habe, wozu das überhaupt nötig sei, meinte sie, dass sie es beim Schreiben von Code brauche und ich es nicht löschen solle.
Oh ... ich glaube, das stimmt.
Der Ansatz von SQLite ist wirklich beeindruckend. Eine Testsuite, die 590-mal so umfangreich ist wie der Code selbst, nicht öffentlich zu machen, bedeutet letztlich, dass „der wahre Wert von Software in der Verhaltensspezifikation liegt“.
Wenn man heutzutage tatsächlich mit AI-Coding-Tools Projekte baut, kann man mit dem README eines bestehenden Projekts, der API-Dokumentation und dem Testcode die Kernfunktionen erstaunlich schnell nachbauen. Das ist etwas, das ich beim Betrieb von sieben Projekten selbst gespürt habe: Paradoxerweise lassen sich gerade Projekte mit guten Tests auch leichter kopieren.
Allerdings gibt es im Fall Cloudflare vs. Vercel einen Punkt, der übersehen wurde: „Kopieren“ und „Betreiben“ sind völlig unterschiedliche Dinge. Um die Edge Cases von Next.js, das Plugin-Ökosystem und sogar die Abhängigkeit von der Community nachzubilden, reicht Testcode allein nicht aus. Letztlich ist der Burggraben wohl eher die Kombination aus Testcode, Community und Betriebs-Know-how.
Ich betreibe als Solo-Entwickler sieben Projekte, und dieser Artikel trifft einen wunden Punkt.
Dank AI-Coding-Tools ist die Geschwindigkeit in der frühen Entwicklung zwar wahnsinnig gestiegen, aber Code, der ohne Tests schnell aufgetürmt wurde, wird am Ende zur Refactoring-Hölle. Vor allem wenn man mehrere Services gleichzeitig betreibt, hat man bei Projekten ohne Tests jedes Mal Angst, dass an anderer Stelle etwas kaputtgeht, sobald man auch nur eine einzige Funktion anfasst.
Die Metapher „Tests = Burggraben“ trifft es genau. Konkurrenten können den Code zwar kopieren, aber eine Test-Suite zu duplizieren, die Tausende von Edge Cases abdeckt, ist deutlich schwieriger. Gerade weil AI zwar gut Code erzeugen kann, für das Erstellen sinnvoller Testszenarien aber noch immer Domänenwissen von Menschen nötig ist, gilt das umso mehr.
Allerdings gibt es je nach Bereich auch Fälle, in denen Testcode kaum Coverage hat, deshalb gibt mir das schon zu denken. Dort scheint man im Vergleich zu anderen Bereichen gute Software noch nicht so gut entwickeln zu können.
Könnten Sie mir vielleicht sagen, um welchen Bereich es sich handelt? (Nicht als Angriff gemeint, ich bin wirklich nur ehrlich neugierig.)
Der Bereich, in dem ich arbeite, ist zwar nicht ganz so extrem, aber ich forsche und entwickle im AI-Bereich.
Neben den allgemein viel genutzten Frameworks kommt es auch vor, dass die Zielumgebung, in der das Modell tatsächlich deployt wird, von der Umgebung abweicht, in der es trainiert wurde.
Manche Operationen werden nicht unterstützt, sodass man plattformspezifische Custom-Operationen erstellen muss. In solchen Fällen kann man oft nicht direkt in der Entwicklungsumgebung testen.
Manchmal modelliert man das Modell auch selbst. Dafür kann man zwar mit bestimmten Daten Testcode schreiben, aber je nach Datensatz ändern sich die Werte probabilistisch, und Phänomene wie explodierende Werte zu bestimmten Zeitpunkten lassen sich mit Testcode nur schwer abdecken.
Ich vermute, es gibt wohl einige Umgebungen, in denen Tests noch schwieriger sind als bei mir.
Das ist nur meine persönliche Meinung, aber ich vermute, dass das vor allem Bereiche betrifft, in denen häufig Notebooks verwendet werden oder in denen Antworten probabilistisch ausfallen, wie im AI-Bereich oder bei Game-Clients.
Darüber spreche ich in meinem Umfeld auch oft, und letztlich denke ich, dass es später schwierig sein wird, den gesamten Code im Detail zu prüfen. Deshalb kann es bei wirklich wichtiger Logik gravierende Folgen haben, wenn man sie nicht unbedingt testet.
Das wurde auch unten im Artikel ergänzt; es hieß, dass auch tldaw seine Tests privat laufen lässt (war wohl ein Scherz).
https://github.com/tldraw/tldraw/issues/8082
Wenn Sie sich Wie wird SQLite getestet? ansehen,
ist SQLite zwar vollständig offen, aber es gibt 590-mal mehr Testcode als Quellcode, und dieser ist komplett nicht öffentlich.
Es gibt 100 % Branch-Coverage, Hunderte Millionen Testfälle und es werden mehr als 1 Milliarde Mutationstests durchgeführt.
Ich bin in das Thema gegangen und habe gelesen, dass es wohl „nur ein Witz“ ist.
War wohl nur ein Joke-Test.
Oh, verstehe. Ich hatte nur den oberen Teil gesehen, haha.
Der Kerngedanke „Tests statt Source“ scheint wirklich zu stimmen. Ich bin mir allerdings nicht sicher, ob eine Strategie tragfähig ist, bei der man nicht Open Testing betreibt, sondern nur Open Source macht. Ich denke auch, dass man wahrscheinlich gut darin sein wird, Testfälle aus dem Source abzuleiten..
Da lag ich falsch.
https://de.news.hada.io/topic?id=26988
Das scheint mit diesem Artikel zusammenzuhängen. Bei Open Source könnte man bei der Veröffentlichung von Testcode inzwischen wohl vorsichtiger werden.