# tdd Published articles for tdd. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Extreme Programming remains relevant for building software teams in 2026 DevFeed: [Extreme Programming remains relevant for building software teams in 2026]() Original publisher: [Read original article]() Author: Anton Zaides Published: 2026-08-18T06:01:00Z Content type: opinion Language: en Sources: [Manager.dev]() Topics: [Programming](), [Development](), [Refactoring](), [Test-driven development](), [pair\_programming](), [Code review]() Tags: [code](), [code-quality](), [development](), [pair-programming](), [programming](), [redesign](), [tdd]() ### AI overview The author revisits Kent Beck's Extreme Programming after experiencing frustration with Scrum and the pressures facing modern engineering teams. The article argues that XP remains relevant because it combines five values, 14 principles, and numerous practices aimed at improving both software and team life, rather than reducing the methodology to TDD and pair programming alone. ### Source excerpt A method created 30 years ago is still your best guide for building software ## How a Tech Lead Encouraged Testing in Legacy Code DevFeed: [How a Tech Lead Encouraged Testing in Legacy Code]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-08-04T06:02:15Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [Test-driven development](), [legacy](), [clean-code](), [Template](), [Software Engineering]() Tags: [clean-code](), [legacy-code](), [tdd](), [tech-lead](), [training](), [unit-tests]() ### AI overview This opinion article recounts how an engineering leader struggled to introduce testing and clean-code practices across multiple companies. As a Tech Lead, the author created a testable Clean Architecture template, recruited developers who valued quality, built an initial module, and trained the team to use the approach. ### Source excerpt "We don't have time to write the code twice." ## AI Coding Tip 029 - Stop Using One Model for Everything DevFeed: [AI Coding Tip 029 - Stop Using One Model for Everything]() Original publisher: [Read original article]() Author: Maxi Contieri Published: 2026-07-26T15:08:02Z Content type: opinion Language: en Sources: [Maximiliano Contieri - Software Design]() Topics: [coding](), [ai-coding](), [Testing](), [Test-driven development]() Tags: [ai-coding](), [coding](), [cost](), [review](), [scope](), [tdd](), [testing]() ### AI overview The article argues that AI coding pipelines should assign different models to planning, coding, reviewing, and testing. It recommends using fresh context, automated test harnesses, independent reviewers, model rotation, and separate models for TDD stages to reduce shared blind spots, vendor dependence, and missed edge cases. ### Source excerpt TL;DR: Assign a different model to each pipeline stage since none excels at planning, coding, reviewing, and testing alike. Common Mistake ❌ You open one chat with your favorite model and ask it to p ## TDD in Legacy Code - Maintainable Component Tests - Backend DevFeed: [TDD in Legacy Code - Maintainable Component Tests - Backend]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-07-02T06:02:41Z Content type: tutorial Language: en Sources: [Optivem Journal]() Topics: [Back end](), [Test-driven development](), [legacy]() Tags: [api](), [backend](), [component](), [erp](), [legacy](), [legacy-code](), [refactor](), [tdd](), [tests]() ### AI overview A tutorial on refactoring brittle backend component tests that are coupled to a backend API and ERP system, with the goal of making them more maintainable. ### Source excerpt Many Backend Teams write unmaintainable Backend Component Tests - coupled to the Backend API and ERP. I'll show you how to refactor these brittle tests. ## Why Legacy Code Turns Small Changes Into Multi-Day Firefighting DevFeed: [Why Legacy Code Turns Small Changes Into Multi-Day Firefighting]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-06-30T06:02:36Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [legacy](), [Test-driven development](), [Development](), [Software]() Tags: [dev](), [engineering](), [legacy-code](), [tdd]() ### AI overview This commentary examines how legacy code can turn a small change into days of investigation and risk. It argues that tangled dependencies, missing tests, and outdated code prevent senior developers from improving architecture and make routine maintenance frustrating. ### Source excerpt The field took twenty minutes. Everything around it took three days. ## The AI-Assisted Engineering Workflow I Use Day to Day DevFeed: [The AI-Assisted Engineering Workflow I Use Day to Day]() Original publisher: [Read original article]() Author: Alex Razvant Published: 2026-06-28T13:01:33Z Content type: tutorial Language: en Sources: [Neural Bits]() Topics: [AI-assisted coding](), [Loop Engineering](), [Test-driven development](), [Claude Code](), [codex](), [Production Engineering](), [coding]() Tags: [ai](), [claude](), [claude-code](), [codex](), [coding-agents](), [engineering](), [production](), [tdd](), [validation](), [workflow]() ### AI overview The article presents a controlled workflow for AI-assisted engineering with Claude, Codex, and other coding agents. It describes intake, task decomposition, test-driven development, bounded implementation, review gates, system validation, and sign-off while keeping the engineer involved throughout. ### Source excerpt How I structure intake, slicing, TDD, implementation, review gates, system validation, and signoff when working with Claude, Codex, and coding agents in production engineering work. ## 10 Lessons learned when building Charlie DevFeed: [10 Lessons learned when building Charlie]() Original publisher: [Read original article]() Published: 2026-04-05T00:00:00Z Content type: article Language: en Sources: [Mutt0-ds Notes]() Topics: [AI Agent](), [Development](), [Large Language Model](), [Architecture & Design](), [Testing]() Tags: [ai-agent](), [anthropic](), [architecture](), [development](), [evals](), [financial](), [llm](), [openai](), [tdd]() ### AI overview The author shares lessons from building Charlie, an AI agent designed for financial institutions. The excerpt emphasizes keeping agent systems simple, designing evaluation pipelines around real-world financial queries, and using flexible, provider-agnostic architecture. It argues that direct retrieval-to-explanation paths can be more robust and faster for many questions, while evaluations must reflect the system's actual context and edge cases. ### Source excerpt Last week, we launched Charlie, our first AI Agent, specifically designed and tailored for financial institutions. While designing and... ## The Way of TDD DevFeed: [The Way of TDD]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2026-03-10T12:24:00Z Content type: article Language: en Sources: [Google Testing Blog]() Topics: [Test-driven development](), [Test coverage](), [Development](), [Algorithm](), [Code]() Tags: [algorithm](), [article](), [bartosz-papis](), [bugs](), [code](), [development](), [quality](), [refactor](), [tdd](), [test](), [test-coverage](), [tests](), [tott]() ### AI overview This article explains Test-Driven Development as a red-green-refactor cycle: write a failing test, make it pass with minimal production code, and then refactor. It describes reported benefits and limitations, and demonstrates the process by modifying a voting algorithm to support abstentions. ### Source excerpt This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Bartosz Papis Test-Driven Development (TDD) is the practice of working in a structured cycle where writing tests comes before writing production code. The process involves three steps, sometimes called the red-green-refactor cycle: Write a failing test Make the test pass by writing just enough production code Refactor the production code to meet your quality standards Research shows TDD has several benefits: it improves test coverage, reduces the number of bugs, increases confidence, and facilitates code reuse. This practice also helps reduce distractions and keep you in the flow. TDD also has its limitations and is not a silver bullet! See the Wikipedia article about TDD for a detailed explanation and references. Here is a short practical example. Assume you need to modify the following voting algorithm to support the option for voters to abstain: def outcome(ballots): if ballots.count(Vote.FOR) > len(ballots) / 2: return "Approved" return "Rejected" 1. We start by writing a failing test - as expected, the test doesn't even compile: def test_abstain_doesnt_count(self): self.assertEqual(outcome([Vote.FOR, Vote.FOR, Vote.AGAINST, Vote.ABSTAIN]), "Approved") 2. We fix the compilation error by including the missing enum option: class Vote(Enum): FOR = 1 AGAINST = 2 ABSTAIN = 3 Now that the test compiles, we fix the production code to get all tests passing: def outcome(ballots): if ballots.count(Vote.FOR) > (len(ballots) - ballots.count(Vote.ABSTAIN)) / 2: return "Approved" return "Rejected" 3. We now refactor the code to improve clarity, and complete an iteration of the TDD cycle: def outcome(ballots): counts = collections.Counter(ballots) return "Approved" if counts[Vote.FOR] > counts[Vote.AGAINST] else "Rejected" Learn more about TDD in the book Test Driven Development: By Example, by Kent Beck. ## Why the Author Is Skeptical of Test-Driven Development DevFeed: [Why the Author Is Skeptical of Test-Driven Development]() Original publisher: [Read original article]() Author: January Published: 2026-01-29T00:00:00Z Content type: opinion Language: en Sources: [Drew DeVault]() Topics: [Test-driven development](), [Testing](), [test-coverage]() Tags: [software-testing](), [tdd](), [test-coverage](), [testing](), [tests](), [unit-test]() ### AI overview The author argues that test-driven development can provide useful rapid feedback and test coverage, but warns that it may shape code around testability and cannot ensure that tested behavior matches actual software requirements. ### Source excerpt I've gotten a lot of flack throughout my career over my disdain towards test-driven development (TDD). I have met a lot of people who swear by it! And, I have also met a lot of people who insisted that I adopt it, too, often with the implied threat of appealing to my boss if appealing to me didn't work. The basic premise of TDD, for those unaware, is that one first writes a unit test that verifies the expected behavior for some code they want to write, observes the new test fail, and then one writes the implementation, iterating on it until the test passes. The advantage of this approach is, first, to ensure that your codebase is adequately covered by testing, and, second, to provide you a rapid feedback loop to assist in your work. I have often found elements of TDD to be quite useful. Using a unit test or something similar to provide an efficient rapid feedback loop is a technique which I have employed many times. However, I am and have always been skeptical of the cult which arises around automated software testing and in particular TDD. A lot of people adopt an unquestioning loyalty to TDD, building tools and practices and vibes around the idea. It's often too much. The flaw with TDD is that, while it ensures that you have a test for every function you write, it also exerts an influence on the tested codebase, shaping the code to be as "testable" as possible, which only sometimes leads to better code. Moreover, TDD has no means of ensuring that the behavior that your tests verify is the right behavior for your software to have. Software with a thousand passing tests and 100% test coverage could be doing whatever the user or the business or whatever needs it to, but it could just as easily not meet the requirements in spite of those comprehensive tests - and in any case it gives you confidence in your work, which may or may not be misplaced. The cult of TDD exploits the fact that TDD is very good at making you feel like a good, diligent programmer. That rapid fee ## Claude Code AI best practices DevFeed: [Claude Code AI best practices]() Original publisher: [Read original article]() Author: Daniel Moka Published: 2025-08-23T05:00:29Z Content type: tutorial Language: en Sources: [Craft Better Software]() Topics: [Claude Code](), [Claude](), [Development](), [Artificial Intelligence](), [VS Code Extension](), [vs-code](), [Test-driven development]() Tags: [ai](), [claude-code](), [coding](), [development](), [ide](), [patterns](), [prompt](), [tdd](), [vs-code]() ### AI overview This developer article shares practical Claude Code workflow advice, including using its VS Code extension, adding Claude.md onboarding documentation to a repository, and following an explore-then-plan-then-code process. The author presents these practices as ways to improve alignment, collaboration, maintainability, and edge-case discovery. ### Source excerpt The future of coding isn't autocomplete of AI. It's collaboration with AI. ## TDD & Commit: Is unit testing harmful? What about Rework/Refactoring? DevFeed: [TDD & Commit: Is unit testing harmful? What about Rework/Refactoring?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-26T06:54:19Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Refactoring](), [Unit testing]() Tags: [refactoring](), [tdd](), [testing](), [unit-testing](), [video]() ### AI overview A video talk examines how test-driven development relates to unit testing, refactoring, rework, and commit practices. It argues that testing problems usually stem from unclear intent, churn, poor test design, or misplaced tests rather than TDD itself. ### Source excerpt A recording from Denis Čahuk's live video ## TDD, TBD, Dynamic Teaming: What would a great CTO do? DevFeed: [TDD, TBD, Dynamic Teaming: What would a great CTO do?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-25T10:42:13Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Development](), [Agile]() Tags: [agile](), [leadership](), [legacy](), [metrics](), [mocking](), [tdd](), [team](), [testing]() ### AI overview This webinar connects test-driven development with dynamic team structures, trunk-based development, onboarding, and technical leadership. It argues that TDD and clear design seams can reduce onboarding friction, while measurement choices such as story points and pull-request counts influence team behavior and may obscure change friction. ### Source excerpt You're a CTO overwhelmed with improvement initiatives and pressure from your product team to stop with the Agile nonsense and just ship things. How do you balance your focus and execution? ## Should TDD be Mandatory? Why are so few teams using it? DevFeed: [Should TDD be Mandatory? Why are so few teams using it?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-24T13:33:16Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [engineering-culture](), [Testing]() Tags: [culture](), [engineering](), [experimentation](), [tdd](), [testing]() ### AI overview This article argues that TDD should neither be mandatory nor banned. Successful adoption depends more on psychological safety, cultural buy-in, team autonomy, and room for experimentation than on enforcement. It also presents TDD as a way to support earlier feedback and safer delivery under change. ### Source excerpt Popularity is not a good measure for quality. The best litmus test for engineering culture is an ongoing effort to learn and experiment with a small part of your bets. ## TDD: Getting out of the never-tester mindset DevFeed: [TDD: Getting out of the never-tester mindset]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-23T07:10:16Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Mocking]() Tags: [coaching](), [gatekeeping](), [tdd](), [team](), [testing]() ### AI overview This session examines why developers and teams struggle to adopt test-driven development. It argues that testing resistance often comes from systemic blockers such as gatekeeping, fragile delivery processes, limited psychological safety, and unclear testing goals. It presents coaching questions and emphasizes that TDD cannot overcome a dysfunctional working context on its own. ### Source excerpt Teams often lose the testing battle before it has begun due to their in-grained identity as not-testers or being in a certain camp: TDD, anti-TDD, old-school, new-age, vibe coder, etc. ## Understanding Mocks, Stubs, Fakes, and Shunts in Test-Driven Development DevFeed: [Understanding Mocks, Stubs, Fakes, and Shunts in Test-Driven Development]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-21T08:05:36Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Test-driven development](), [Testing]() Tags: [mocking](), [tdd](), [testing](), [tests](), [video]() ### AI overview A recording from Denis Čahuk's live video explains the differences between mocks, stubs, fakes, and shunts, and examines how overusing or misunderstanding test doubles can create tangled tests. It discusses testing outgoing commands with mocks and how difficult mocking setups may indicate design problems. ### Source excerpt A recording from Denis Čahuk's live video ## How Mocking Affects Software Design and Testability DevFeed: [How Mocking Affects Software Design and Testability]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-19T07:45:14Z Content type: tutorial Language: en Sources: [Crafting Tech Teams]() Topics: [Mocking](), [Testing](), [Test-driven development](), [Refactoring](), [test-coverage]() Tags: [coverage](), [mocking](), [mongodb](), [refactoring](), [tdd](), [testing]() ### AI overview A recorded talk examines when mocks are useful, common misconceptions about mocking and TDD, and how excessive or poorly chosen mocks can constrain software design and testability. It discusses multi-mock tests, database mocking, and designing narrow seams around dependencies. ### Source excerpt If you've ever felt like your tests get in the way of refactoring, or like mocks make everything harder rather than simpler this stream is for you. ## ☀ While I'm out: A 6-part deep dive on TDD, engineering culture and leadership DevFeed: [☀ While I'm out: A 6-part deep dive on TDD, engineering culture and leadership]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-07-17T14:03:59Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [engineering-culture]() Tags: [engineering-culture](), [leadership](), [mocking](), [tdd](), [testing](), [unit-testing]() ### AI overview The author announces a six-part Substack series based on earlier coaching streams and webinars. The series covers testing, mocking, TDD, engineering culture, team dynamics, and leadership, with posts scheduled from July 19 through July 26. ### Source excerpt A Summer Deep-Dive on Testing, Design, and Teams from our previous webinars and coaching streams. ## Using Claude-Swarm to Upgrade Ruby Projects DevFeed: [Using Claude-Swarm to Upgrade Ruby Projects]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2025-06-21T01:00:00Z Content type: tutorial Language: en Sources: [Daniel Doubrovkine]() Topics: [Ruby](), [upgrade](), [Claude Code](), [AI Development](), [Command-line interface](), [Test-driven development](), [Code review]() Tags: [ai](), [ai-development](), [claude](), [claude-code](), [code-review](), [command-line](), [ruby](), [shopify](), [tdd](), [tools](), [upgrade]() ### AI overview This tutorial explains how to use claude-swarm to coordinate multiple Claude Code instances for upgrading Ruby projects. It covers installing the claude_swarm gem, initializing a swarm configuration, and defining a Ruby upgrade workflow with Bash access. ### Source excerpt One of my colleagues wrote a pretty awesome tool called claude-swarm that orchestrates multiple Claude Code instances as a collaborative AI development team. At Shopify, we are attempting to use it to generate Ruby unit tests at some scale with an army of AI test agents (think a "Ruby Expert" paired with a "TDD Practitioner" and a "Code Review Nitpicker"). But for the purposes of this post, let's just upgrade Ruby in a few projects. First, ensure that you have a working version of command-line Claude code with a monthly subscription, since you will be having a lot of tokens for breakfast. $ claude "Say hello." ╭───────────────────────────────────────────────────╮ │ ✻ Welcome to Claude Code! │ ╰───────────────────────────────────────────────────╯ > Say hello. ⏺ Hello! I'm Claude Code, ready to help you with your software engineering tasks. What can I assist you with today? Install the claude_swarm gem. Note that the gem name has an _. $ gem install claude_swarm $ claude-swarm --help Commands: claude-swarm clean # Remove stale session symlinks claude-swarm generate # Launch Claude to help generate a swarm configuration interactively claude-swarm help [COMMAND] # Describe available commands or one specific command claude-swarm init # Initialize a new claude-swarm.yml configuration file ... Create a claude-swarm.yml. version: 1 swarm: name: "Ruby Upgrade Swarm" main: lead_developer before: - "echo 'Getting started ...'" instances: lead_developer: description: "Lead developer to coordinate Ruby upgrades." directory: .. model: opus allowed_tools: - Bash prompt: | Find the Ruby projects in this directory. Do not recurse further than 3 levels deep. For each project, identify the Ruby version used. Print the project name next to the ruby version only. For the first 5 projects with a Ruby version older than 3.5.5 use ruby_upgrader to upgrade the Ruby version. connections: [ruby_upgrader] ruby_upgrader: description: "Upgrades a Ruby project." model: opus allowed_tools: - Bash ## TDD: The Missing Protocol for Effective AI Assisted Software Development DevFeed: [TDD: The Missing Protocol for Effective AI Assisted Software Development]() Original publisher: [Read original article]() Author: John Riccardi Published: 2025-05-28T18:14:00Z Content type: tutorial Language: en Sources: [8th Light Insights]() Topics: [Test-driven development](), [Large Language Model](), [AI Development](), [Software Engineering](), [Prompt Engineering]() Tags: [ai](), [coding](), [core](), [engineering-and-devops](), [llm](), [prompting](), [quality](), [software-development](), [tdd]() ### AI overview This article argues that test-driven development provides a structured communication protocol for collaborating with AI coding tools. It explains that large language models often struggle with broad, ambiguous software tasks because developers provide insufficient context, constraints, and edge cases, and recommends writing tests first before using AI to implement solutions. ### Source excerpt Bottom Line Up Front The goal isn't to replace human developers but to offload repetitive tasks so we can focus on creativity and architecture--where human expertise is irreplaceable. Start your next feature by writing tests first, then let AI help implement the solution. You'll deliver higher quality code faster, with greater confidence. Large Language Models Aren't as Simple as They Seem Large language models (LLMs) have a fundamental flaw: they appear deceptively easy to use. That blinking cursor invites you to interact with an LLM as if it were another human being--one that understands your intent, the context of your questions, and the logic behind your requests. You type a prompt, hit send, and then disappointment sets in. While it's exciting to watch it generate multiple files of code for your new project, the moment you try to run that code, it often fails to work as intended or doesn't run at all. As you continue prompting it to iterate on previous outputs, the LLM may go in circles, change direction entirely, or simply stall. The core issue is that we ask LLMs to do too much while providing too little direction and context--effectively setting them up for failure. It's like the classic PB&J experiment, where a father follows his children's sandwich-making instructions literally. We believe we're being clear, but we drastically underestimate how much implicit context AI lacks about the problems we're trying to solve. What we need is a better communication protocol--one that structures our requests in a way AI tools can reliably understand and execute. Why AI Struggles With Large, Ambiguous Problems Despite their impressive capabilities, current LLMs consistently struggle with large, vague problems. The issue is not primarily token limitations or technical constraints; it's a deeper problem in how we frame our requests. When developers ask AI to "build a complete authentication system" or "create an e-commerce checkout flow," they inadvertently set the AI up to ## .NET Refactoring Series: Episode 1 -- How to Approach Service Refactoring DevFeed: [.NET Refactoring Series: Episode 1 -- How to Approach Service Refactoring]() Original publisher: [Read original article]() Author: giovanni-ferrari Published: 2025-04-02T13:19:47Z Content type: tutorial Language: en Sources: [Backend Job: skill, salary and insights - Codemotion Magazine]() Topics: [Refactoring](), [.NET](), [Testing](), [Test-driven development](), [Code]() Tags: [backend](), [complexity](), [github](), [how-to](), [net](), [refactoring](), [tdd](), [test](), [testing]() ### AI overview This first episode of a .NET refactoring series explains how to approach refactoring a production service that has become difficult to extend or scale. Using an OrderService example, it emphasizes separating technical concerns from business logic and writing tests before refactoring, including unit testing and Test-Driven Development. ### Source excerpt Every developer, sooner or later, faces the challenge of refactoring a project that started as a proof of concept but ended up in production. For me, this is an exciting task. It gives me the opportunity to learn new things, complain about "who the hell wrote this code?", and apply my knowledge to make the... Read more The post .NET Refactoring Series: Episode 1 -- How to Approach Service Refactoring appeared first on Codemotion Magazine. ## Our Tech Journey Update & Planning DevFeed: [Our Tech Journey Update & Planning]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-04-02T09:36:57Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [AI Agent](), [Artificial Intelligence](), [Continuous Deployment (CD)](), [Test-driven development](), [Code review]() Tags: [ai](), [ai-agent](), [code-review](), [continuous-deployment](), [tdd](), [tech](), [update](), [video]() ### AI overview The article outlines a 10-week live content plan covering AI assistance for tech businesses, AI agent setups, development workflows, testing, deployment, code review, and the economics of AI in product engineering. It also provides streaming platforms and scheduling information. ### Source excerpt A recording from Denis Čahuk's live video ## Clean Code Discussion DevFeed: [Clean Code Discussion]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-03-06T15:10:02Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [clean-code](), [Test-driven development](), [Testing](), [Refactoring](), [Code quality](), [Tooling](), [legacy]() Tags: [clean-code](), [code-quality](), [legacy](), [refactoring](), [tdd](), [testing](), [tooling]() ### AI overview A recording of a live discussion about Clean Code and Test-Driven Development. The speakers examine testing challenges, test smells, refactoring, tooling, code-quality practices, TDD adoption, team practices, event modeling, and legacy systems. ### Source excerpt A recording from Denis Čahuk's live video ## TDD Schools Discussion DevFeed: [TDD Schools Discussion]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-02-19T13:58:16Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development]() Tags: [live](), [recording](), [tdd](), [video]() ### AI overview A recording from Denis Čahuk's live video about TDD schools. ### Source excerpt A recording from Denis Čahuk's live video ## Why Would you Write Tests before Code? DevFeed: [Why Would you Write Tests before Code?]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-02-13T17:42:58Z Content type: opinion Language: en Sources: [Crafting Tech Teams]() Topics: [Test-driven development](), [Testing](), [Software Engineering]() Tags: [development](), [monitoring](), [performance-testing](), [tdd](), [testing](), [unit-testing]() ### AI overview The article explains test-driven development as writing tests before implementation to create refactoring capability early. It distinguishes capability testing, which verifies intended feature behavior, from regression testing, which records unexpected user-replicated behavior, and argues that TDD adoption depends more on a mindset shift toward higher-quality delivery than on additional workshops. ### Source excerpt The Test-Driven Elephant In The Room [Next page]()