各位，

正如你们在上一篇博客中所知道的，我正在学习openSAP课程，为ABAP编写可测试的代码。我们刚刚完成了第2周，很抱歉，这有点令人失望，因为还有一个"数字输入，数字输出"的例子。感觉就像是电视连续剧中的一个"填充"情节，当一个明星演员去戒毒所时，突然开始探索子情节。

我们确实了解了测试驱动开发（TDD）原则，ABAP单元测试就是为了支持这个原则。TDD的主要假设是，您甚至在编写任何"真实"代码之前就创建了测试。所以，如何租用服务器，你从"给定X，Y是预期的"这样的测试开始，很自然，它会立即失败，因为（duh）应该将X转换成Y的代码还没有被编写出来。如果对你来说，这看起来从愚蠢到白痴，近乎疯狂，你并不孤单。但是任何TDD的信徒都会告诉你，这一点都不傻，恰恰相反，如果你完全接受它并永远改变你对软件开发的看法，这是一种非常有效的方法。我对那些愚蠢的例行公事并不陌生。例如，我在车里总是系好安全带。没有例外。即使我只需要把车开出车道，我还是用安全带。事实证明，安全带可以防止车祸中的重伤和死亡。尽管以行人速度行驶5米时发生事故的风险很低，但使用安全带对我来说只是一种反射。更不用说，这是北卡罗来纳州的法律。

作为任何理性的人，我喜欢有事实证据的时候。但由于某些原因，对TDD美德的讨论在我看来不像科学家争论两种不同的理论，更像是著名的《白痴》中的"电解质"对话。未来的人类一直在用一种名为Brawndo（"解渴剂"）的饮料代替普通水来浇灌庄稼，因为制造商告诉他们，这种饮料"含有电解质"，而这正是植物所需要的。当普通乔建议用水时，会出现以下对话：

TDD有多棒并不缺乏信息。老实说，我从来没有要求过，不知怎么的我已经知道了。因为这周在openSAP阵营的表现缓慢而低落，我去Google寻找故事的另一面，即TDD批评。互联网的好处是你可以很容易地找到许多事实和支持你观点的人。然后你可以回头找到同样多的事实和支持完全相反观点的人。

在我的谷歌搜索中，一个最热门的结果是一个关于TDD缺点的StackExchange问题，大数据服务，什么叫大数据分析，它提供了一个很好的答案：

原型在许多其他帖子中被提到，作为TDD似乎没有意义的一个例子。当遇到这样的争论时，"TDD狂热者"很快收回"那就不要使用TDD"，但这开始发出混合的信息。

关于这个问题的另一个StackExchange问题可能是由我写的：一个单独的开发人员在与实际用例作斗争。

两个最受欢迎的答案（第二个来自叔叔）鲍勃本人）不要真正回答这个问题，按照熟悉的"你怎么可能不爱TDD"的思路去做。但稍不受欢迎的答案提供了更为平衡和实际的观点。例如，与赌博有一个有趣的比较：

开发投资回报率是一个重要因素。回到我的安全带的例子，如果不需要2秒钟就可以系好安全带呢？如果花了5分钟呢？在这种情况下，你可能会开始跳过它时，只是把车从一个停车场到另一个停车场。（旁注：如果你真的想强制执行某件事，就需要尽可能不费吹灰之力。我想这就是ABAP单元测试对SAP世界中TDD的意义所在。不确定它是否成功。）

有许多其他有趣的文章提供了不同的观点TDD。这篇文章把它看作一种心理现象：TDD是强迫症（强迫症）的一种形式吗？这篇文章分析了向初学者展示TDD的挑战。

如果你有时间，新零售企业应用中心，你会很容易找到关于"TDD是软件开发史上最好的东西"、"TDD已经死了"、"TDD还没有死"、"TDD应该死"、"为什么比TDD好得多"的各种帖子。甚至有一个博客有着奇特的标题，几乎，但不是完全不同于TDD（顺便说一句，它解释了"代码气味"这个词，在课程的第一周把我搞糊涂了）。

后一个博客的特点是引用"TDD是一种学习的技能……"但是如果TDD是一种工具呢？在与队友讨论openSAP课程时，我提到它让我想起了一些涉及融化巧克力的食谱。他们从如何建造双层锅炉的冗长说明开始。要做到这一点，你需要一个坚固的锅和适量的开水，以及一个大小合适的耐热碗，可以放在锅上而不接触水。然后你在那只碗里慢慢搅拌和融化巧克力，时间不详。

如果你是19世纪70年代的厨房女佣，这些都是很好的说明。在本世纪，我们有微波炉，只用一个碗就能在1分钟内融化整个巧克力棒。许多专业人士会声称，双锅法可以更好地控制温度，避免意外烧焦巧克力。说得好。不过，根据我的经验，只要你经常检查和搅拌巧克力，就很难燃烧，智能建站软件，而且当它被烤成巧克力饼时，没有一个人知道我用的是微波炉。