TDD -内外对内

Question

在与使用TDD从内到外构建应用程序之间有什么区别？

下面是我读到的关于TDD和单元测试的书：

测试驱动开发:通过示例

测试驱动开发:实用指南:实用指南

开发高质量框架和应用程序的真实世界解决方案

微软.NET中的测试驱动开发

xUnit测试模式:重构测试代码

单元测试的艺术:以.Net为例

开发基于测试的面向对象软件-->这个很难理解，因为JAVA不是我的主要语言:)

几乎所有的人都解释了TDD的基本原理和单元测试，但是很少提到构建应用程序的不同方式。

我注意到的另一件事是，在编写应用程序时，这些书籍(如果不是全部的话)都忽略了设计阶段。他们更专注于快速编写测试用例，并让设计自行出现。

然而，我在xUnit测试模式中遇到了一个段落，其中讨论了人们处理TDD的方式。外面有两所学校，里面有两所学校。

遗憾的是，这本书并没有详细阐述这一点。我想知道这两种情况之间的主要区别是什么。

我应该什么时候使用每一种？

对于一个TDD初学者来说，哪一个更容易掌握？

每种方法的缺点是什么？

有没有专门讨论这个话题的材料？

Answer 1

内外都是相当罕见的术语，我经常听说/读到经典学校和伦敦学校。

• 内部-外(经典学校，自下而上)：您从组件/班级级别(内部)开始，并将测试添加到需求中。随着代码的发展(由于重构)，出现了新的协作者、交互和其他组件。TDD完全指导设计。
• 在外面(伦敦学校，自上而下或马丁·福勒( Martin )所称的“嘲笑TDD” )：你知道前面的互动和协作者(尤其是那些高层的)，从那里开始(顶级)，嘲笑必要的依赖。对于每个已完成的组件，您将转移到以前模拟的协作者，然后再从TDD开始，在那里创建实际的实现(尽管使用过，但由于抽象而不需要这些实现)。请注意，外接方法很符合雅格尼原则。

这两种方法都不是唯一的，它们都有各自的位置，取决于你所做的事情。在大型企业解决方案中，设计的部分部分来自于架构师(或预先存在)，您可以从“伦敦风格”方法开始。另一方面，当您面临一种情况，您不确定您的代码应该如何(或它应该如何适合您的系统其他部分)，它可能更容易从一些低端组件开始，让它随着更多的测试、重构和需求的引入而发展。

无论您使用哪种方法，它通常都是情景性的。

对于进一步的阅读，有一个非常有趣的谷歌群帖，讨论了这个区别(可能)是如何产生的，以及为什么伦敦可能不是最合适的名字。

Answer 2

简短的回答:和往常一样，这将取决于你的编码偏好和团队方法。

由内而外的编码是伟大的，因为你总是有一些有用的东西。缺点是它不一定能帮助你到达一个完全不同的地方。用这种方式规划路线是很困难的。类似地，编写外部代码的缺点是不一定具有快速迭代开发的好处，也不一定看到代码结构深处可能产生的所有机会和模式。

我逐渐相信这两种发展风格都是重要的，事实上，在团队中有多种风格是有帮助的。其思想是，内到外是伟大的创造积木，而外部在思维提供了形式结构和方向。

我的部分推理来自一个非常流行的思想流派，目前它促进迭代开发，而迭代开发通常是内到外开发的同义词。我相信迭代开发是伟大的，当您没有太大的进展。但我认为，与单纯的迭代过程相比，宏观的思考对于某些类型的创新和走向不那么明显的地方是非常宝贵的。适当的管理，内外结合可以是一个非常有效的组合。

Answer 3

您应该将C#中的敏捷原则、模式和实践添加到该列表中。我不知道他为什么在结尾加上"in C#“。这些书根本不是语言，亚马逊没有得到5颗星的唯一原因是那些对他的例子感到失望的人。

作者主张，只要有可能，您就应该尝试编写外部代码，并在很大程度上依赖于进化设计，我同意他的说法。他的推理是，当我们添加功能时，我们的设计总是会进化的。如果我们从添加特性的低级组件开始，我们就会意识到这些组件并没有做我们希望它们做的事情，或者东西需要移动。这可能会变得相当昂贵，特别是当您每次将功能从一个类移动到另一个类时，您需要在所有单元测试项目中执行相同的操作。

另一方面，如果首先确定应用程序应该做什么，则需要为外部接口编写代码。随着特性的添加和测试代码的不断增加，您可以将应用程序重构为更多的类，但是在进行重构工作时，您编写的原始单元测试仍然有效。因此，您完全从外部开始，继续重构到越来越多的低级类，同时向这些内部类添加额外的单元测试，但是很少需要移动和重写单元测试。

然而，如果您确定您的应用程序将需要一个特定的低级别子系统(而且您的公司可能已经在其他应用程序中需要这样的子系统)，那么现在应该先从一个低级别的构建块开始，然后在此基础上构建应用程序。