[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-19-eigenschaftsbasiertes-testen-fuzzing-foundry":3},{"article":4,"author":60},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":39,"related_articles":40},"d7000000-0000-0000-0000-000000000119","a0000000-0000-0000-0000-000000000072","Deep EVM #19: Eigenschaftsbasiertes Testen fuer Smart Contracts — Fuzzing mit Foundry","deep-evm-19-eigenschaftsbasiertes-testen-fuzzing-foundry","Eigenschaftsbasiertes Testen und Fuzzing fuer Smart Contracts mit Foundry erkunden. Fuzz-Eingaben, Invarianten-Tests und differentielles Testen von Huff, Yul und Solidity.","## Ueber Unit-Tests hinaus\n\nUnit-Tests verifizieren spezifische Szenarien, aber Smart Contracts sind adversarialen Eingaben ausgesetzt — von jeder Adresse, mit jedem Wert, in jeder Reihenfolge. Eigenschaftsbasiertes Testen dreht das Paradigma um: Statt erwartete Ausgaben fuer spezifische Eingaben festzulegen, definieren Sie Eigenschaften, die fuer ALLE Eingaben gelten muessen.\n\n## Fuzz-Testing mit Foundry\n\nFoundry generiert automatisch zufaellige Eingaben fuer Testfunktionen:\n\n```solidity\n\u002F\u002F Foundry erkennt Fuzz-Parameter automatisch\nfunction testFuzz_transfer(\n    address to,\n    uint256 amount\n) public {\n    vm.assume(to != address(0));\n    vm.assume(amount \u003C= totalSupply);\n    \n    deal(token, address(this), amount);\n    \n    uint256 balBefore = token.balanceOf(address(this));\n    token.transfer(to, amount);\n    uint256 balAfter = token.balanceOf(address(this));\n    \n    \u002F\u002F Eigenschaft: Balance muss um genau amount sinken\n    assertEq(balBefore - balAfter, amount);\n}\n```\n\nFoundry fuehrt diesen Test standardmaessig 256 Mal mit unterschiedlichen Zufallswerten aus.\n\n## Invarianten-Tests\n\nInvarianten sind Bedingungen, die IMMER gelten muessen, unabhaengig davon, welche Funktionen in welcher Reihenfolge aufgerufen werden:\n\n```solidity\ncontract InvariantTest is Test {\n    TokenHandler handler;\n    \n    function setUp() public {\n        handler = new TokenHandler(token);\n        targetContract(address(handler));\n    }\n    \n    \u002F\u002F Diese Funktion wird nach jeder zufaelligen Aufrufsequenz geprueft\n    function invariant_totalSupplyConstant() public {\n        assertEq(token.totalSupply(), INITIAL_SUPPLY);\n    }\n    \n    function invariant_balanceSumEqualsTotal() public {\n        uint256 sum = 0;\n        for (uint i = 0; i \u003C actors.length; i++) {\n            sum += token.balanceOf(actors[i]);\n        }\n        assertEq(sum, token.totalSupply());\n    }\n}\n```\n\n## Differentielles Fuzzing: Huff vs. Solidity\n\n```solidity\nfunction testFuzz_differential_balanceOf(\n    address account,\n    uint256 initialBalance\n) public {\n    vm.assume(initialBalance \u003C= type(uint128).max);\n    \n    \u002F\u002F Gleiche Anfangsbedingungen setzen\n    deal(huffToken, account, initialBalance);\n    deal(solidityToken, account, initialBalance);\n    \n    \u002F\u002F Beide abfragen\n    (bool s1, bytes memory r1) = huffToken.staticcall(\n        abi.encodeWithSignature(\"balanceOf(address)\", account)\n    );\n    (bool s2, bytes memory r2) = solidityToken.staticcall(\n        abi.encodeWithSignature(\"balanceOf(address)\", account)\n    );\n    \n    \u002F\u002F Ergebnisse muessen identisch sein\n    assertEq(s1, s2);\n    assertEq(r1, r2);\n}\n```\n\n## Best Practices\n\n1. **vm.assume() sparsam verwenden** — Zu viele Annahmen reduzieren die Testabdeckung\n2. **Eigene Handler schreiben** — Handler steuern, welche Funktionen der Fuzzer aufruft\n3. **Ghost-Variablen** — Eigene Buchhaltung neben dem Contract fuehren\n4. **Genug Durchlaeufe konfigurieren** — foundry.toml: `[fuzz] runs = 10000`\n5. **Fehlschlaege reproduzieren** — Foundry speichert Seeds fuer reproduzierbare Fehler\n\n## Fazit\n\nEigenschaftsbasiertes Testen und Fuzzing finden Fehler, die Unit-Tests uebersehen. Fuer Huff-Contracts, die kein Sicherheitsnetz haben, ist differentielles Fuzzing gegen eine Solidity-Referenz die staerkste Waffe in Ihrem Testarsenal.","\u003Ch2 id=\"ueber-unit-tests-hinaus\">Ueber Unit-Tests hinaus\u003C\u002Fh2>\n\u003Cp>Unit-Tests verifizieren spezifische Szenarien, aber Smart Contracts sind adversarialen Eingaben ausgesetzt — von jeder Adresse, mit jedem Wert, in jeder Reihenfolge. Eigenschaftsbasiertes Testen dreht das Paradigma um: Statt erwartete Ausgaben fuer spezifische Eingaben festzulegen, definieren Sie Eigenschaften, die fuer ALLE Eingaben gelten muessen.\u003C\u002Fp>\n\u003Ch2 id=\"fuzz-testing-mit-foundry\">Fuzz-Testing mit Foundry\u003C\u002Fh2>\n\u003Cp>Foundry generiert automatisch zufaellige Eingaben fuer Testfunktionen:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F Foundry erkennt Fuzz-Parameter automatisch\nfunction testFuzz_transfer(\n    address to,\n    uint256 amount\n) public {\n    vm.assume(to != address(0));\n    vm.assume(amount <= totalSupply);\n    \n    deal(token, address(this), amount);\n    \n    uint256 balBefore = token.balanceOf(address(this));\n    token.transfer(to, amount);\n    uint256 balAfter = token.balanceOf(address(this));\n    \n    \u002F\u002F Eigenschaft: Balance muss um genau amount sinken\n    assertEq(balBefore - balAfter, amount);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Foundry fuehrt diesen Test standardmaessig 256 Mal mit unterschiedlichen Zufallswerten aus.\u003C\u002Fp>\n\u003Ch2 id=\"invarianten-tests\">Invarianten-Tests\u003C\u002Fh2>\n\u003Cp>Invarianten sind Bedingungen, die IMMER gelten muessen, unabhaengig davon, welche Funktionen in welcher Reihenfolge aufgerufen werden:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">contract InvariantTest is Test {\n    TokenHandler handler;\n    \n    function setUp() public {\n        handler = new TokenHandler(token);\n        targetContract(address(handler));\n    }\n    \n    \u002F\u002F Diese Funktion wird nach jeder zufaelligen Aufrufsequenz geprueft\n    function invariant_totalSupplyConstant() public {\n        assertEq(token.totalSupply(), INITIAL_SUPPLY);\n    }\n    \n    function invariant_balanceSumEqualsTotal() public {\n        uint256 sum = 0;\n        for (uint i = 0; i < actors.length; i++) {\n            sum += token.balanceOf(actors[i]);\n        }\n        assertEq(sum, token.totalSupply());\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"differentielles-fuzzing-huff-vs-solidity\">Differentielles Fuzzing: Huff vs. Solidity\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-solidity\">function testFuzz_differential_balanceOf(\n    address account,\n    uint256 initialBalance\n) public {\n    vm.assume(initialBalance <= type(uint128).max);\n    \n    \u002F\u002F Gleiche Anfangsbedingungen setzen\n    deal(huffToken, account, initialBalance);\n    deal(solidityToken, account, initialBalance);\n    \n    \u002F\u002F Beide abfragen\n    (bool s1, bytes memory r1) = huffToken.staticcall(\n        abi.encodeWithSignature(\"balanceOf(address)\", account)\n    );\n    (bool s2, bytes memory r2) = solidityToken.staticcall(\n        abi.encodeWithSignature(\"balanceOf(address)\", account)\n    );\n    \n    \u002F\u002F Ergebnisse muessen identisch sein\n    assertEq(s1, s2);\n    assertEq(r1, r2);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"best-practices\">Best Practices\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>vm.assume() sparsam verwenden\u003C\u002Fstrong> — Zu viele Annahmen reduzieren die Testabdeckung\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Eigene Handler schreiben\u003C\u002Fstrong> — Handler steuern, welche Funktionen der Fuzzer aufruft\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ghost-Variablen\u003C\u002Fstrong> — Eigene Buchhaltung neben dem Contract fuehren\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Genug Durchlaeufe konfigurieren\u003C\u002Fstrong> — foundry.toml: \u003Ccode>[fuzz] runs = 10000\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Fehlschlaege reproduzieren\u003C\u002Fstrong> — Foundry speichert Seeds fuer reproduzierbare Fehler\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"fazit\">Fazit\u003C\u002Fh2>\n\u003Cp>Eigenschaftsbasiertes Testen und Fuzzing finden Fehler, die Unit-Tests uebersehen. Fuer Huff-Contracts, die kein Sicherheitsnetz haben, ist differentielles Fuzzing gegen eine Solidity-Referenz die staerkste Waffe in Ihrem Testarsenal.\u003C\u002Fp>\n","de","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:30.364627Z","Eigenschaftsbasiertes Testen fuer Smart Contracts — Fuzzing mit Foundry","Eigenschaftsbasiertes Testen und Fuzzing fuer Smart Contracts. Fuzz-Eingaben, Invarianten-Tests und differentielles Testen von Huff vs. Yul vs. Solidity.","Smart-Contract-Fuzzing Foundry",null,"index, follow",[22,27,31,35],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000021","Foundry","foundry",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000013","Security","security",{"id":36,"name":37,"slug":38,"created_at":26},"c0000000-0000-0000-0000-000000000018","Yul","yul","Blockchain",[41,48,54],{"id":42,"title":43,"slug":44,"excerpt":45,"locale":12,"category_name":46,"published_at":47},"d0000000-0000-0000-0000-000000000680","Warum Bali 2026 zum Impact-Tech-Hub Südostasiens wird","warum-bali-2026-impact-tech-hub-suedostasiens","Bali rangiert auf Platz 16 unter den Startup-Ökosystemen Südostasiens. Mit einer wachsenden Konzentration von Web3-Entwicklern, AI-Nachhaltigkeits-Startups und Eco-Travel-Tech-Unternehmen formt die Insel ihre Nische als Impact-Tech-Hauptstadt der Region.","Ingenieurwesen","2026-03-28T10:44:49.720230Z",{"id":49,"title":50,"slug":51,"excerpt":52,"locale":12,"category_name":46,"published_at":53},"d0000000-0000-0000-0000-000000000679","ASEAN-Datenschutz-Flickenteppich: Compliance-Checkliste für Entwickler","asean-datenschutz-flickenteppich-compliance-checkliste-entwickler","Sieben ASEAN-Länder verfügen mittlerweile über umfassende Datenschutzgesetze mit unterschiedlichen Einwilligungsmodellen, Lokalisierungsanforderungen und Sanktionsstrukturen. Eine praktische Compliance-Checkliste für Entwickler.","2026-03-28T10:44:49.715484Z",{"id":55,"title":56,"slug":57,"excerpt":58,"locale":12,"category_name":46,"published_at":59},"d0000000-0000-0000-0000-000000000678","Indonesias 29-Milliarden-Dollar-Digitaltransformation: Chancen für Softwareunternehmen","indonesias-29-milliarden-dollar-digitaltransformation-chancen-softwareunternehmen","Indonesias IT-Dienstleistungsmarkt wird voraussichtlich 2026 29,03 Milliarden Dollar erreichen, gegenüber 24,37 Milliarden im Jahr 2025. Cloud-Infrastruktur, AI, E-Commerce und Rechenzentren treiben das schnellste Wachstum in Südostasien.","2026-03-28T10:44:49.697275Z",{"id":13,"name":61,"slug":62,"bio":63,"photo_url":19,"linkedin":19,"role":64,"created_at":65,"updated_at":65},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]