最近我一直在想这件事，因为我可以清楚地看到TDD的好处。如果开发人员对功能的概念有所了解，我可以很容易地看到测试如何驱动良好的设计。这可能是一个过于简单的陈述，但是从Ive读到的所有内容来看，TDD都主张除了项目体系结构和框架选择之外，我们没有任何设计。话虽这么说，我不得不猜测，即使是最顽固的TDD者，在开始工作时也没有完全空白的心理设计状态

我的问题是：TDD是否可以在高级程序员/设计师/架构师进行类和/或者组件设计，然后将设计交给初级开发人员实施的环境中使用？在这种情况下，测试将不是设计的主要驱动力。我想实现的程序员可以使用测试优先的方法来实现该设计。在那种情况下，它仍然是TDD，还是最好将其称为"测试驱动实现"？这样的事情在现实世界中会奏效吗，还是我们认为我们会遇到TDD最糟糕的部分并提前进行设计？

更新：

我遇到了Roy Osherove的博客，描述了TDD的各种含义：

What are the possible meanings of TDD?
  
  
  Test Driven Development: the idea
  of writing your code in a test first
  manner. You may already have an
  existing design in place.  
  Test Oriented Development: Having unit
  tests of integration tests in your
  code and write them out either
  before or after our write the code.
  Your code has lots of tests. You
  recognize the value of tests but you
  don't necessarily write them before
  you write the code. Design probably
  exists before you write the code 
  Test Driven Design(the eXtreme
  Programming way):  The idea of using
  a test-first approach as a fully
  fledged design technique, where
  tests are a bonus but the idea is to
  drive full design from little to no
  design whatsoever. You design as you
  go. 
  Test Driven Development and
  Design: using the test-first
  technique to drive new code and
  changes, while also allowing it to
  change and evolve your design as an
  added bonus. You may already have
  some design in place before starting
  to code, but it could very well
  change because the tests point out
  various smells.

读完之后，很显然，TDD的"测试驱动设计"风格可能不是这种环境的最佳选择，但"测试驱动开发"风格则可能合适。

解决方案

"TDD advocates that you have no design beyond your project architecture and framework choices

TDD绝对不主张我们在上面描述的内容。

更新：由于问题的更新，我认为值得编辑此答案。

TDD不仅仅是一种测试策略，更是一种设计理念。

我认为这需要重申。TDD与测试无关，也不与"测试优先"开发有关。 TDD是关于根据功能和业务需求驱逐行为的，有些人将其称为进化设计。

但是，只要我们考虑到可测试性，就可以松散地将设计与设计结合起来，那么就没有什么可以阻止建筑师的计划使设计"成形"。我敢肯定，建筑师的设计中考虑了许多非功能性要求。

我肯定会问一个问题，为什么需要预先"计划"整个设计？对开发团队缺乏信任吗？与要求初级人员共享知识和设计相比，有更好的方法，而不是规定完整的代码解决方案。例如，与高级开发人员配对编程。

我经常看到这种情况失败了。架构师的愿景会过度设计，无法测试，不会被广泛理解，并且随着时间的推移会慢慢腐烂，因为数十名开发人员/承包商接触了代码库，无法理解愿景，也没有可以依靠的测试。

我不确定我们对TDD的理解是否与它的一般定义一致，因此也许对此主题进行一些阅读可能会有所帮助。

测试驱动开发主要是关于将测试用例用作代码的接受标准。 IE。只需先编写一个测试用例，然后再进行测试即可。
简短地进行此操作会有所帮助，强烈建议这样做，但对我而言，这并不是问题的核心。

经典的"重复：(添加测试->编写代码以满足测试标准)" *循环与其他实践(例如，由建筑师进行总体项目设计)相处得很好。如果开发人员可以以与编写功能测试用例相同的方式使用设计文档，那么编写适当的测试的工作将变得更加容易，如果我们已经有详细的用例，那么编写工作就容易得多。

* shortened for convenience

在这种环境下，我认为最好使用合同驱动的方法。

架构师描述了要实现的类或者接口的契约。然后，开发人员将生成测试用例以行使合同，并提供代码以执行合同。

例如，看一下Martin Fowler关于Consuder Driven Contracts的文章，该文章描述了这种方法如何与Web服务一起工作：
http://martinfowler.com/articles/consumerDrivenContracts.html

我们的设计过程与问题非常相似。实际上，我们已经通过此过程打破了analisys与实施之间的鸿沟。设计师对他的设计进行了单元测试。

TDD主要是一种设计策略。也就是说，首先编写测试用于驱动生产代码的设计，是的。

这并不意味着我们不需要进行任何前期设计。我认识的几乎每个人在开始TDD周期时已经头脑中有了某种设计。毕竟，我们至少需要了解从何处开始，针对哪个类编写测试。尤其是如果我们也在练习结对编程，建议提前进行简短的设计课程。

另一方面，要获得TDD的全部好处，我们需要能够听听测试为我们提供的有关设计的反馈，并将其纳入重构步骤以相应地适应设计。而且，按照我们所做的工作量，我们可能会发现一些前期设计被浪费了，即使不是有害的，因为它使我们处于次优的方向。当其他人提出设计并缺乏从测试中获得的反馈意见时，这尤其可能使我们陷入麻烦。

因此，我要说的是，在情况下进行TDD并非不可能，但我会寻找一些麻烦。

不管我们是否采用TDD，我都会补充一点，方法似乎有点" Architects Not Code"反模式的味道。我会考虑让高级开发人员至少部分与初级成员配对计划。这将指导初中生，为他们的设计决策提供有价值的反馈，并减少这两个角色之间可能出现的摩擦。