--- title: "Test Driven Development in Web3" canonical: https://wavect.io/blog/test-driven-development/ language: en description: "Why TDD matters in Web3 development, how to apply it to smart contracts and decentralized applications, and why skipping tests costs you more than you think." image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/in/jocr77 5 min read · 17 June 2024 [**Next**](/blog/agile-fixed-pricing/) # Why Test-Driven-Development pays off TL;DR There is no error-free software: even the best engineers ship bugs, which is why tests exist. In test-driven development engineers write tests before implementing the logic, which done properly keeps untested code out of the repository, cuts costs, and contains the technical debt that makes systems fragile. When hiring developers, test their proficiency in testing; a project without tests will eventually die. Related service: [Software Quality Assurance](/services/software-quality-assurance/) ## Why Test-Driven Development Test Driven Development ([TDD](/glossary/tdd/)) is a technique used by experienced software engineers to ensure the state of an application is as intended. In more traditional applications and within the journey of software engineering altogether, testing has been acknowledged and manifested to be part of every successful and professionally crafted software system. Nowadays, there are still tons of companies out there that have the impression that writing tests slows down development, increases costs, and in general is a waste of time. May this article shine a light on why this particular statement cannot be more wrong. ### What Stops Software From Working? There is no such thing as perfectly written software. (Probably) never will be. The term bug was first phrased at Harvard in 1946. At that time, Grace Hopper had popularised a story about a moth that caused problems in an early electromechanical computer. Hopper was working on the Mark II/III computer systems at Harvard where he identified that a moth was trapped in a relay causing problems. Once the moth was removed Hopper phrased the statement within his notes: „First actual case of bug being found“. The term „bug“ was created and used ever since to indicate unexpected behavior in a computer system. What's the likelihood of a certain system having bugs? 100 out of 100 projects. What's the likelihood of having bugs within a certain system, if I hire the best engineers on this planet? 100 out of 100 projects. Hence, hiring better engineers does not solve the problem. It definitely will decrease the amount of bugs, but not their overall presence. That is why tests are written, as there is no error-free software. ![The cost of testing over time](/img/blog/posts/tdd-grace_hopper_bug_hu_2b5a209830cfad25.webp) Grace Hopper's bug (1946) ## TDD: Cutting Costs, Enhancing Quality In Test-Driven Development (TDD), engineers write tests before implementing the logic. Without going into technical details, this leads to the following: It ensures, if done properly, that no untested code is pushed to the repository as you have written a dedicated test upfront. Does this solve the bug problem we have discussed above? Unfortunately, no it does not. But it's one of the best techniques we have to ensure the creation of battle-tested and resilient software. ![Christof Jori](/img/team/christof.webp) "Validate assumptions early to minimize costly mistakes later" What's the difference with [web3](/glossary/web3/) now? Security is a top priority in Web3 development. [Smart contracts](/glossary/smart-contract/) often manage significant amounts of cryptocurrency and other valuable digital assets. Any vulnerability in these contracts can lead to substantial financial losses. TDD plays a crucial role in enhancing security by promoting continuous testing and early identification of potential issues. By catching security flaws early in the development cycle, TDD helps protect against exploits and attacks that could compromise the integrity of a decentralized application. Testing enables engineers to adjust the code base and receive immediate feedback. If tests are written properly, any change to the code base that might lead to a bug will be caught by a test and reported. Importantly, everything mentioned above can be done with simple testing too. Simple testing in the sense of writing a test whenever we think "now" is a good time. Many engineers follow the path: "I write the code now and once I have time, I'll write the test". Which is, to some degree, OK. Better than writing no tests at all! Yet it will never get the resilience levels of TDD, because it entirely misses the point. I happily repeat myself here: "No untested code will reach production". This is what pure TDD ensures. ![The cost of testing over time](/img/blog/posts/tdd-cost-of-testing.svg) Having no tests at all will eventually backfire ## The Silent Killer: Technical Debt Now I still owe you an explanation as to why omitting to write tests will skyrocket engineering and maintenance costs. The key word is [technical debt](/glossary/technical-debt/). Software will always contain bugs. The longer it exists and the bigger it becomes, the more bugs it will produce. This is not something I came up with to underline this section, it is a well-known fact. Consequently, If there is no countermeasure to find and eliminate these bugs, they will live on and influence code that is added to the code base. Regularly. The more features we add to that software, the bigger the problem gets. And then one day, the tower collapses and you are standing in front of a no longer controllable code basis. Leading to a total or partial rebuild of your project. Picture a small town that decides to build a bridge quickly to connect two sides of a river. The engineers, in their rush, skip some safety checks and use lower-quality materials. Initially, the bridge works fine, and everyone is happy with the swift completion. As time goes on, more and more cars start using the bridge. Small cracks appear, but they are ignored because the bridge is still standing. Every new vehicle adds stress, making those cracks larger. One day, a heavily loaded truck drives over the bridge, and it collapses, causing a massive disruption. This is what happens with technical debt in [custom software development](/services/software-development/). Early shortcuts and untested code create hidden problems. As new features are added, these problems grow until the system becomes fragile. Eventually, a seemingly minor change can cause a catastrophic failure, just like the overloaded truck did to the bridge. Without tests to catch and fix issues early, the software becomes unsustainable, leading to skyrocketing costs and, ultimately, collapse. Advice #1: Whenever you hire developers, test their proficiency in testing by asking simple questions: → What is your experience with writing tests? → Which kind of tests do you prefer for this project, and why? → Do we really need to write tests? Advice #2: If they give a S* about testing, they give a S* about your product. Sounds harsh, but is the truth. Your project will eventually die without testing, that is for sure. ## Final thoughts Neglecting software testing not only risks encountering non-functioning software but also undermines the overall quality and reliability of the product. Proper testing is essential not just for identifying bugs and issues but also for ensuring that the software meets user expectations and operates seamlessly in various environments. If you want your product to succeed, you should rely on engineers that rely on testing. QA and production readiness ## Continue through this cluster [Start with the cornerstone**QA for AI-Generated Code**](/blog/qa-for-ai-generated-code/) - [Agentic Testing vs Test Automation: 2026 Pilot Guide](/blog/agentic-testing-vs-test-automation-2026/) - [External QA Benchmark: What We Find in the First 30 Days](/blog/external-qa-benchmark-first-30-days/) - [What Software Maintenance Costs After Launch: A DACH SaaS Benchmark](/blog/software-maintenance-cost-benchmark-dach-saas/) - [Agile De-engineering](/blog/agile-de-engineering/) - [Lovable, Bolt, and Replit App Due Diligence](/blog/lovable-bolt-replit-app-due-diligence/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/in/jocr77 5 min read · 17 June 2024 [**Next**](/blog/agile-fixed-pricing/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/test-driven-development/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/test-driven-development/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "There is no error-free software: even the best engineers ship bugs, which is why tests exist. In test-driven development engineers write tests before implementing the logic, which done properly keeps untested code out of the repository, cuts costs, and contains the technical debt that makes systems fragile. When hiring developers, test their proficiency in testing; a project without tests will eventually die.", "articleBody": " Blog overview/Delivery and QA/QA and production readiness Why Test-Driven-Development pays off TL;DR There is no error-free software: even the best engineers ship bugs, which is why tests exist. In test-driven development engineers write tests before implementing the logic, which done properly keeps untested code out of the repository, cuts costs, and contains the technical debt that makes systems fragile. When hiring developers, test their proficiency in testing; a project without tests will eventually die. Related service: Software Quality Assurance Why Test-Driven Development Test Driven Development (TDD) is a technique used by experienced software engineers to ensure the state of an application is as intended. In more traditional applications and within the journey of software engineering altogether, testing has been acknowledged and manifested to be part of every successful and professionally crafted software system. Nowadays, there are still tons of companies out there that have the impression that writing tests slows down development, increases costs, and in general is a waste of time. May this article shine a light on why this particular statement cannot be more wrong. What Stops Software From Working? There is no such thing as perfectly written software. (Probably) never will be. The term bug was first phrased at Harvard in 1946. At that time, Grace Hopper had popularised a story about a moth that caused problems in an early electromechanical computer. Hopper was working on the Mark II/III computer systems at Harvard where he identified that a moth was trapped in a relay causing problems. Once the moth was removed Hopper phrased the statement within his notes: „First actual case of bug being found“. The term „bug“ was created and used ever since to indicate unexpected behavior in a computer system. What's the likelihood of a certain system having bugs? 100 out of 100 projects. What's the likelihood of having bugs within a certain system, if I hire the best engineers on this planet? 100 out of 100 projects. Hence, hiring better engineers does not solve the problem. It definitely will decrease the amount of bugs, but not their overall presence. That is why tests are written, as there is no error-free software. Grace Hopper's bug (1946) TDD: Cutting Costs, Enhancing Quality In Test-Driven Development (TDD), engineers write tests before implementing the logic. Without going into technical details, this leads to the following: It ensures, if done properly, that no untested code is pushed to the repository as you have written a dedicated test upfront. Does this solve the bug problem we have discussed above? Unfortunately, no it does not. But it's one of the best techniques we have to ensure the creation of battle-tested and resilient software. \"Validate assumptions early to minimize costly mistakes later\" What's the difference with web3 now? Security is a top priority in Web3 development. Smart contracts often manage significant amounts of cryptocurrency and other valuable digital assets. Any vulnerability in these contracts can lead to substantial financial losses. TDD plays a crucial role in enhancing security by promoting continuous testing and early identification of potential issues. By catching security flaws early in the development cycle, TDD helps protect against exploits and attacks that could compromise the integrity of a decentralized application. Testing enables engineers to adjust the code base and receive immediate feedback. If tests are written properly, any change to the code base that might lead to a bug will be caught by a test and reported. Importantly, everything mentioned above can be done with simple testing too. Simple testing in the sense of writing a test whenever we think \"now\" is a good time. Many engineers follow the path: \"I write the code now and once I have time, I'll write the test\". Which is, to some degree, OK. Better than writing no tests at all! Yet it will never get the resilience levels of TDD, because it entirely misses the point. I happily repeat myself here: \"No untested code will reach production\". This is what pure TDD ensures. Having no tests at all will eventually backfire The Silent Killer: Technical Debt Now I still owe you an explanation as to why omitting to write tests will skyrocket engineering and maintenance costs. The key word is technical debt. Software will always contain bugs. The longer it exists and the bigger it becomes, the more bugs it will produce. This is not something I came up with to underline this section, it is a well-known fact. Consequently, If there is no countermeasure to find and eliminate these bugs, they will live on and influence code that is added to the code base. Regularly. The more features we add to that software, the bigger the problem gets. And then one day, the tower collapses and you are standing in front of a no longer controllable code basis. Leading to a total or partial rebuild of your project. Picture a small", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "dateModified": "2026-07-07", "datePublished": "2024-06-17", "description": "There is no error-free software: even the best engineers ship bugs, which is why tests exist. In test-driven development engineers write tests before implementing the logic, which done properly keeps untested code out of the repository, cuts costs, and contains the technical debt that makes systems fragile. When hiring developers, test their proficiency in testing; a project without tests will eventually die.", "headline": "Why Test-Driven-Development pays off", "image": "https://wavect.io/img/blog/headers/header_test-driven-development.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/test-driven-development/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/test-driven-development/", "wordCount": 1310 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/delivery-qa/", "name": "Delivery and QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/qa-production/", "name": "QA and production readiness", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/test-driven-development/", "name": "Test Driven Development in Web3 | ", "position": 5 } ] } ```