这是关于单元测试和测试驱动开发的课程的最后一周，这在ABAP世界引起了全面的战争，因为人们为了捍卫或攻击概念而奋战至死

本周的主题是现有的代码和测试双重框架，这个和那个，返利机器人怎么做，以及其他基本上还没有涵盖的东西。

单元测试关于泰坦尼克号

遗留代码

正如我一直强调的那样，尽管OO ABAP是在2000年用SAP 4.6C引入的，但在这段时间内，它的使用率却低得惊人，因为最近的在线辩论显示，很多人仍然100%地按程序编程，而且团队"缺乏OO知识"。事实上，这门课程的一个好处是让正在学习的人试着了解OO的概念。

我已经发布了大量的博客，阐述了为什么我认为OO是好的，基于很多真实世界的经验，但这显然不是每个人都喜欢的。

无论如何，OO在SAP世界没有真正流行起来的最终结果是，现有的大量代码都是过程性的。因为在互联网上，甚至在本课程中，所有关于如何引入单元测试的例子都假定要更改的程序已经是100%面向对象的，而在实际的程序中是100%程序化的，这往往会让人们认为"这与我无关"，就像Gas Board过去在"这就是生活！"上说的那样。

尽管如此，我还是有可能——我已经做到了——将单元测试与过程性程序结合使用，而不需要对它们进行任何更改。当然，单元测试类必须是面向对象的，我并不是说这很容易，你需要在SETUP和TEARDOWN方法中做很多工作，但是这是可以做到的，在我的例子中，我使用了这种技术来将一个似乎不能做任何正确的事情的程序转换成一个执行完美的程序，尽管有着永无止境的功能变化来自功能性业务所有者。

尽管开始将过程性程序稍微OO化要比花很长时间使用复杂的设置方法来处理全局变量等少得多。

这涉及到将数据库调用等提取到数据库访问类的方法中，或者UI调用UI类等等。对于一个庞大的程序程序来说，你不可能一下子做到这一点，你也不想这么做。这就是一直流行的"幸福岛"出现的地方。

传统鳟鱼

我以前说过，我要一字不差地再说一遍。我说，当你对一个大程序有一个改变，为新的行为写一个测试，它失败了，改变代码，测试通过了。然后你有一个单元测试。就这样吧，不要费心重构任何东西。

当程序的下一个变化出现时，下一周，程序的一个完全不同的部分，重复这个过程。然后你有两个测试，而且你知道第二个变化并没有破坏第一个。在这一点上，你有0.05%的程序在测试中。

如果你严格执行这一点，那么过一段时间你将受益于我所说的"没有人是完全满意的"这一法则，也就是"如果一个程序的一部分被人使用，他们迟早会希望它被改变"。因此，五年之后，程序中的每一个部分都会受到变更请求的影响，因此会有某种单元测试。这是非常简单的，但这是一般的想法。新的程序应该从一开始就有测试。

没有人会满意

股票期权

一个问题是"第一类"程序中的选择权和参数。这些是全局变量，正如我们所看到的，它们是单元测试的毒药。因为全局变量是"接缝"，所以必须有一个特殊的类来存储这些值。在现实生活中，企业云服务器，你只是在类中填充用户输入的值；在测试中，你在类中填充虚假值。

我已经做了一段时间了，希望有更好的方法，但没有。如果有请告诉我。课程指导者指出的一个好处是，SELECT-OPTIONS必须非常短，否则会出现语法错误，因此最终会出现S\u DFRM之类的值，而类中的目标变量的名称最多可以有30个字符，比如DATE\u FROM\u RANGE之类的。

什么东西每咬一口都有榛子？

完全改变话题！本周课程的标题是"现有代码"，但实际上大部分内容都是关于各种测试双重框架的。

到目前为止，我们一直在手动创建我们的测试双重框架（mock，无论你想叫它们什么），将接口设置为"部分实现"，然后用我们的假数据手动编码我们正在"重新定义"的方法。

有一种不同的方法来实现这一点，据我所知，这是ABAP740带来的。实际上有一个开源的Z项目叫做ZMOCKA，它在较低版本上也做同样的事情。SAP肯定已经注意到了这一点，并构建了自己的版本，这实际上对ZMOCKA项目的作者来说是相当令人高兴的。无论如何，最初的概念来自Java，这是ABAP版本。

您在这里所做的不是编写测试双精度的定义和实现，而是通过将所需的接口传递给CL\u ABAP\u TESTDOUBLE来创建测试双精度，然后返回一个正确类型的实例，将其注入到被测代码中。