在上一篇文章中，我谈到了什么是伟大的软件，根据我正在关注的第一本OOA&D书籍，它恢复到3个方面：

现在我想用一些东西来加强这一点，在我看来，这一点也起到了重要作用：

伟大的软件是可测试的。

无论你的代码看起来多么漂亮，如果你不能正确地测试你的程序，维护/增强它将是相当困难的。这对用户来说是一个大问题，只是他们可能不知道或不关心，但对你来说也是，因为软件和应用程序在不断地变化、演变，在某些情况下变异成与原来的范围非常不同的其他东西-让我们实实在在地在这里。猜猜看谁会做这些肮脏的工作？

我们经常会发现自己处于这样一种情况：要么我们被要求更改自己的代码——更可取，但很可能我们不记得当时写的任何东西。或者我们需要修改其他人的代码——不太理想，可能性很高。如果代码无法测试，我们如何确保在实现更改后不会破坏任何东西？我在过去10年中看到的传统方法是：

在开发环境中进行一些无关紧要的测试，有时检查是否没有转储。运输至质量环境，大数据培训，再次测试。交给功能顾问，他/她进行相同的测试。发布给用户。第一个测试：运行时错误。

"当然，他们是用X数据集测试的，我们用Y数据集测试的"将是第一个借口。即使这是真的，真正的问题是软件很弱，不健壮，没有真实的数据就无法测试。换句话说，程序有依赖性，因此不可能进行测试。

我读了很多关于测试驱动开发的书，现在我开始觉得自己像《黑客帝国》里的尼奥：我懂功夫。说真的，以我的经验，TDD是交付好的、高质量软件的一种方式？嗯，这感觉像是一次旅行，有很多东西要学。我再一次向未来推荐paulhardybook ABAP，它是我的指南，也启发了我开始写这些文章。

首先，ABAP单元不一定是一个纯粹的技术工具，人工智能网络，只提供给开发者。在ABAP程序上运行单元测试不需要开发人员密钥，因此任何拥有显示程序/类的适当授权的人都应该能够运行测试。那么，如果我们的业务专家和职能顾问也参与进来呢？

通过行为驱动的发展，我们可以做到这一点。保罗·哈代早在2013年就说过，我现在才发现这一点。BDD是关于测试方法内部的简化，所以在abap单元中标记为测试的方法将具有对开发人员、业务分析师和用户有意义的描述。您可以通过设置每个测试方法来实现这一点，这些方法补充了短语"It should…"。然后在这个方法中，按照"给定…"模式创建3个helper方法…。（初始条件）"，移动大数据，"当…。（测试方法）"，"然后…。（check result）".

这是我为ZCL\u INVENTORY类重构测试类的方法：

因此，哪个云服务器好，我们的想法是包含"IT SHOULD"方法，因为它们直接来自于函数规范文档。在我的示例中，ZCL\u INVENTORY类应该能够：

向库存添加吉他。保护库存不受重复对象的影响。在清单中搜索一把吉他。

让我们看看add \u guitar \u to \u inventory（）方法的实现：

这读起来就像简单的英语：为了将吉他添加到清单中，我们从一些吉他属性开始，在我们将吉他添加到清单中并检查它是否成功包含在内之后。所以你为这个方法运行一个测试，如果没有绿灯，你就知道这个过程的这一部分出了问题在存货清单上签个名。ABAP单元的断言进入这一部分：

这不是很好吗？最后，我们完成了一个编写得很好的单元测试，大数据查询，它对当前的开发人员和以后的开发人员、功能顾问、业务用户甚至管理人员都很有意义。