Die beste Zeit, um einen Fehler zu finden, ist nicht in der Produktion
Die meisten Entwickler machen sich nicht so viele Gedanken über das Schreiben von Code. Sie sorgen sich eher darum, zu spät zu entdecken, dass sich der Code anders verhält als erwartet. Das Lesen der Testdokumentation von Newton hat meine Denkweise zu diesem Problem verändert. Wir sehen Fotos an, bevor wir sie posten, und prüfen die Route, bevor wir eine lange Fahrt antreten. Eine Richtlinie ohne Tests einzusetzen fühlt sich wie das Überspringen beider Schritte an.
Die Dokumentation von Newton folgt einem einfachen Prinzip: erst testen, später ausrollen. Entwickler können einzelne Komponenten validieren oder den vollständigen Ablauf simulieren, bevor irgendetwas die Blockchain erreicht. Der letzte Schritt, simulatePolicy(), sammelt Oracle-Daten, bewertet die Rego-Richtlinie und zeigt, ob das Ergebnis erlauben oder verweigern lautet – bevor die Richtlinie ausgerollt wird.
An genau dieser Stelle hörte sich die Dokumentation für mich nicht mehr wie eine reine Anleitung zum Debugging an. Sie begann, eine Frage zu beantworten, die Entwickler oft erst stellen, nachdem etwas kaputtgegangen ist: „Was wird diese Richtlinie tatsächlich tun?“ Anstatt die Antwort durch eine fehlgeschlagene Transaktion zu entdecken, macht die Simulation die Entscheidung sichtbar – während Änderungen noch sicher und kostengünstig sind.
Newton trennt Tests außerdem in verschiedene Phasen. simulatePolicyData() prüft, ob das Oracle die erwarteten Daten zurückgibt. simulatePolicy() validiert den vollständigen Autorisierungsablauf. simulateTask() hilft dabei, vorhandene Tasks während des Debuggings erneut abzuspielen. Jedes Tool konzentriert sich auf ein Problem, statt zu versuchen, alles auf einmal zu lösen.
Eine Einschränkung ist erwähnenswert. simulateTask() läuft lokal, daher trainiert es nicht die gesamte Operator-Pipeline. Entwickler müssen weiterhin simulatePolicy() nutzen, um den vollständigen Ausführungsablauf vor dem Deployment zu validieren.
Mein Fazit: Zuverlässige Systeme entstehen nicht dadurch, dass man Fehler vermeidet. Sie entstehen dadurch, dass man die meisten Fehler findet, bevor Nutzer sie überhaupt zu sehen bekommen.
Quelle: Newton Protocol Documentation (Testing & Debugging, Testing Policies & Oracles, SDK Reference). Persönliche Analyse, sofern ausdrücklich angegeben. NFA.DYOR. #Newt $NEWT @NewtonProtocol
Die meisten Entwickler machen sich nicht so viele Gedanken über das Schreiben von Code. Sie sorgen sich eher darum, zu spät zu entdecken, dass sich der Code anders verhält als erwartet. Das Lesen der Testdokumentation von Newton hat meine Denkweise zu diesem Problem verändert. Wir sehen Fotos an, bevor wir sie posten, und prüfen die Route, bevor wir eine lange Fahrt antreten. Eine Richtlinie ohne Tests einzusetzen fühlt sich wie das Überspringen beider Schritte an.
Die Dokumentation von Newton folgt einem einfachen Prinzip: erst testen, später ausrollen. Entwickler können einzelne Komponenten validieren oder den vollständigen Ablauf simulieren, bevor irgendetwas die Blockchain erreicht. Der letzte Schritt, simulatePolicy(), sammelt Oracle-Daten, bewertet die Rego-Richtlinie und zeigt, ob das Ergebnis erlauben oder verweigern lautet – bevor die Richtlinie ausgerollt wird.
An genau dieser Stelle hörte sich die Dokumentation für mich nicht mehr wie eine reine Anleitung zum Debugging an. Sie begann, eine Frage zu beantworten, die Entwickler oft erst stellen, nachdem etwas kaputtgegangen ist: „Was wird diese Richtlinie tatsächlich tun?“ Anstatt die Antwort durch eine fehlgeschlagene Transaktion zu entdecken, macht die Simulation die Entscheidung sichtbar – während Änderungen noch sicher und kostengünstig sind.
Newton trennt Tests außerdem in verschiedene Phasen. simulatePolicyData() prüft, ob das Oracle die erwarteten Daten zurückgibt. simulatePolicy() validiert den vollständigen Autorisierungsablauf. simulateTask() hilft dabei, vorhandene Tasks während des Debuggings erneut abzuspielen. Jedes Tool konzentriert sich auf ein Problem, statt zu versuchen, alles auf einmal zu lösen.
Eine Einschränkung ist erwähnenswert. simulateTask() läuft lokal, daher trainiert es nicht die gesamte Operator-Pipeline. Entwickler müssen weiterhin simulatePolicy() nutzen, um den vollständigen Ausführungsablauf vor dem Deployment zu validieren.
Mein Fazit: Zuverlässige Systeme entstehen nicht dadurch, dass man Fehler vermeidet. Sie entstehen dadurch, dass man die meisten Fehler findet, bevor Nutzer sie überhaupt zu sehen bekommen.
Quelle: Newton Protocol Documentation (Testing & Debugging, Testing Policies & Oracles, SDK Reference). Persönliche Analyse, sofern ausdrücklich angegeben. NFA.DYOR. #Newt $NEWT @NewtonProtocol