Ich nutze schon länger das Set aus rolldown, oxlint und oxfmt und war sowohl mit der Geschwindigkeit als auch mit den Ergebnissen sehr zufrieden.
oxc-minify von oxc ist zwar noch Alpha, aber ich nutze es einfach vertrauensvoll.
Die Tab-Unterstützung im Editor oder die Transparenz- und Ebenenunterstützung in Paint fand ich zwar gut, aber nach und nach wird es doch immer voller.
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.
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.
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.
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..
Ist es jetzt nicht eher besser? Wenn man sich schneller bewegt als alle anderen, scheint man ziemlich rasch zum Experten werden zu können. Auch im Bereich KI gibt es noch viel zu tun … im Moment kann man ja gerade erst sagen, dass man einigermaßen gut programmieren kann.
Ich öffne VS Code gar nicht mehr und lasse auf der GitHub-Seite direkt mit dem Copilot-Agenten an mehreren Projekten programmieren. Der Agent zeigt dabei sogar direkt per Playwright Screenshots von Webseiten an – alles funktioniert.
Dadurch werden mehrere brachliegende Toy-Projekte wiederbelebt. :-)
Ziemlich beeindruckend. Obwohl der Text kurz ist, leuchtet es sofort ein. Die Sicherheit des Testcodes könnte sogar wichtiger sein als die des Quellcodes.
Ein guter Satz für Menschen wie mich, die nicht gut darin sind, Dinge tatsächlich umzusetzen.
Man hört inzwischen sogar, dass Entwickler jetzt mit Claude Code auch Design machen sollen – braucht Design dann keine Reviews/Qualitätsprüfung?
Ich finde die zusätzlichen Artikel, die man zusammen ansehen kann, sehr gut.
Ich nutze schon länger das Set aus rolldown, oxlint und oxfmt und war sowohl mit der Geschwindigkeit als auch mit den Ergebnissen sehr zufrieden.
oxc-minify von oxc ist zwar noch Alpha, aber ich nutze es einfach vertrauensvoll.
Die Tab-Unterstützung im Editor oder die Transparenz- und Ebenenunterstützung in Paint fand ich zwar gut, aber nach und nach wird es doch immer voller.
Oh, verstehe. Ich hatte nur den oberen Teil gesehen, haha.
Ich bin in das Thema gegangen und habe gelesen, dass es wohl „nur ein Witz“ ist.
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.
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.
Viel Erfolg!
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..
Das wirkt, als würde man Der pragmatische Programmierer für Studierende lesen, und das gefällt mir ausgesprochen gut.
Danke, ich habe es mir angesehen. Wie ermitteln Sie das Geschäftsgebiet?
Ist es jetzt nicht eher besser? Wenn man sich schneller bewegt als alle anderen, scheint man ziemlich rasch zum Experten werden zu können. Auch im Bereich KI gibt es noch viel zu tun … im Moment kann man ja gerade erst sagen, dass man einigermaßen gut programmieren kann.
Ich öffne VS Code gar nicht mehr und lasse auf der GitHub-Seite direkt mit dem Copilot-Agenten an mehreren Projekten programmieren. Der Agent zeigt dabei sogar direkt per Playwright Screenshots von Webseiten an – alles funktioniert.
Dadurch werden mehrere brachliegende Toy-Projekte wiederbelebt. :-)
Eine witzige Antwort, haha
Ziemlich beeindruckend. Obwohl der Text kurz ist, leuchtet es sofort ein. Die Sicherheit des Testcodes könnte sogar wichtiger sein als die des Quellcodes.
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.
Wie bei der Entwicklung macht Gitarrespielen am meisten Spaß, wenn ich es ganz nach meinem eigenen Gefühl machen kann.