﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Dan Bunea commented on Test (Drive Design) -&gt; Code -&gt; Refactor</title><description>Fully Agree. The test actually is the design stage, as when writing the tests you're designing the classes, methods, how they work and interact. It is as you said Test Driven Design. 
</description><link>http://ayende.com/2545/test-drive-design-code-refactor#comment4</link><guid>http://ayende.com/2545/test-drive-design-code-refactor#comment4</guid><pubDate>Wed, 13 Jun 2007 07:02:43 GMT</pubDate></item><item><title>Wendy commented on Test (Drive Design) -&gt; Code -&gt; Refactor</title><description>I agree that the biggest design component of TDD is the test writing, it is driving the design of the responsibility and interaction of the components. 
  
  
The refactoring step keeps you focus on simplicity in making each test pass (since you save refactoring for later). So, yes the refactoring does design the class, but it is implementation design.  
  
  
Sometimes in the refactoring you decide to pull components out of the class, but if you are focused on testing and single responsibility, you test drive those before you get to the refactoring phase.
</description><link>http://ayende.com/2545/test-drive-design-code-refactor#comment3</link><guid>http://ayende.com/2545/test-drive-design-code-refactor#comment3</guid><pubDate>Tue, 12 Jun 2007 13:55:46 GMT</pubDate></item><item><title>James Kovacs commented on Test (Drive Design) -&gt; Code -&gt; Refactor</title><description>The whole point of TDD is a design technique that encourages loosely-coupled architectures. When you are writing your initial test, you are designing what the API looks like. You are pinning down expected functionality. You then write the simplest code possible (but no simpler) so that you have a working system. Then you look for opportunities to improve the design and refactor to your deeper understanding of the system. As Keith says above, it's all about design. It's about avoiding big design up front (BDUF), which has plagued our industry for so many years. It's about writing flexible software - software that can be changed easily as requirements change and knowledge is gained. I'm probably preaching to the converted as most folks reading your blog already know this.
</description><link>http://ayende.com/2545/test-drive-design-code-refactor#comment2</link><guid>http://ayende.com/2545/test-drive-design-code-refactor#comment2</guid><pubDate>Mon, 11 Jun 2007 22:02:56 GMT</pubDate></item><item><title>Keith Nicholas commented on Test (Drive Design) -&gt; Code -&gt; Refactor</title><description>Your both right.  The whole thing is design
  
  
Expressing your intent is design
  
Writing code is design
  
Simplifying is design
  
Introducing or removing levels of indirection is design
  
</description><link>http://ayende.com/2545/test-drive-design-code-refactor#comment1</link><guid>http://ayende.com/2545/test-drive-design-code-refactor#comment1</guid><pubDate>Mon, 11 Jun 2007 21:35:10 GMT</pubDate></item></channel></rss>