我将在这里写下我从SAP过程编程、手动单元测试到SAP面向对象编程和测试驱动开发（TDD）的经历。

当我编写第一个ABAP程序时，我还学习了SAP面向对象编程教育和其他各种非SAP的面向对象编程书籍（如Java或C语言），设计模式，干净的代码，测试自动化，openSAP在线免费课程如何编写可测试的代码。综上所述，我开始觉得这些书/资料中描述的优点很有道理。我在互联网上也读到了很多悲观的信息，同样来自SAP社区，这些东西在SAP中不能很好地工作。在这种信息混乱的情况下，我还是觉得面向对象编程、自动化测试、设计模式给人很好的感觉。所以我开始创建第一个本地类。这给我的代码带来的价值微乎其微，但我在面向对象语法方面有所改进，而且这至少促使我更好地实现有关干净代码的书籍中的规则（尽管对于干净代码规则，行业云，OOP并不是不可避免的）。然后我为一些本地类创建了第一个自动化测试，因此我改进了SAP单元测试框架的语法（当时我没有使用mock，也没有使用TDD）。这些改进对于我的下一步非常重要，但是在我的旧过程程序和带有本地类的新过程程序之间仍然有一个很小的差别。我决定从OOP和TDD中获得更多的价值，所以我决定开始创建全局类，虽然我有一个印象，我不太需要它们，但我不知道如何以这样的方式创建它们，使它们可以重用。后来我发现在全局类中编写大部分代码是不可避免的还有其他几个原因。

我在这里给其他开发人员的建议是开始在全局类中创建大部分代码，在本地类中创建很少的代码（对于范围非常有限的事情）。

我开始认为我需要全局接口和模拟依赖关系。为了从OOP和自动化单元测试中充分获益，我们必须开始创建全局接口。它们也非常有用，对于这种编码风格来说是不可避免的。

当我创建第一个自动化单元测试时，我认为mock是奇怪的，spies或adhoc测试类对于单元测试来说就足够了。很快我就发现了模拟在单元测试中的巨大威力。关于mock，我的建议是，它们是处理依赖关系、使测试更具可维护性的非常好的方法，人工智能大数据，并且需要用来实现单元测试的更大潜力。我无法想象现在不使用mock。

当我开始使用抽象类和多态性时，我发现我开始在单元测试中有很多重复代码，所以我开始使用抽象测试类，在一个地方有测试类的重复代码。

在我更好地理解了干净的代码规则、OOP、全局类、全局类之后接口，自动单元测试，模拟，抽象测试类，然后我完全意识到了解它们是多么重要。现在我开始看到我的代码开始变得更加可重用、可维护、稳定、可测试（这是一些重要的软件质量标准）–这些事情我不能在更高的层次上用我的过程式编码风格来做。尤其是当我开始编写大型程序时，我意识到我能够控制它们。

当我能够进行自动单元测试和面向对象编程时，我开始意识到先创建测试比在我完成程序后创建测试更有优势。我看到首先创建测试（就像在关于TDD的书中描述的那样）帮助我，引导我，创建真正的可测试代码，可测试OOP。我开始更多地考虑界面。所以当我来到这里的时候，这让我明白TDD实际上是不可避免的。如果我要花更多的时间创建这些测试，物联网教室，并且我需要重新设计我的程序使其可测试，那么为什么我要在程序完成后编写自动单元测试代码呢？如果我先创建测试，那么就可以避免这种情况。所以对我来说TDD不是关于个人的选择，而是关于节省时间。当然，大数据可视化平台，也有一些情况会导致我在更新程序后编写测试——例如，如果我发现我错过了一些场景，并且程序已经编码，或者如果我在测试中发现了缺陷……我的大多数自动测试都是在我的程序更新之前准备的。

关于单元测试的维护——我感到非常惊讶我花在维护过去的单元测试上的时间太少了。这几乎没什么…有一次我决定创建一个集成测试而不是单元测试（使用这个SAP单元测试框架），我在单元测试中更新数据库，我没有模仿它，这个测试失败了一次，尽管我没有碰它。除此之外，维护时间为0。这是一个令人担心的问题，即维护需要很多时间。如果程序中的所有依赖项都是孤立的，单元测试只测试程序的内部逻辑，那么目前我不知道为什么单元测试应该停止工作（失败），如果没有其他开发人员接触它们。另外，我也不确定我是否能够理解，维持自己一段时间（几个月）后，我自己的测试。我很惊讶这是很容易的。