在我之前的博客中，我提到了DOCs。我还在博客中提供了一个非常基本的单元测试示例。我将在这个博客的最后扩展同样的例子。如果你不理解这里使用的某些缩写，或者想了解一些基本概念，那么我建议你看看我以前的博客，网站用云服务器，我写的是test doubles，后面提到了当DOC是数据库对象时如何处理ABAP中的依赖关系。然后，它从数据库中读取雇员的雇用日期，并计算服务年限。在我们的开发系统中，我们在执行测试之前创建必要的测试数据。稍后，当单元测试运行时，访问数据库的查询也将执行。加载的测试数据将由测试用例获取，我们的所有测试都将成功运行。到目前为止，一切正常。好的！！

图1：在单元测试中访问DOC

现在让我们假设这整套代码是从开发系统中传输出来的。此代码将到达多个系统，其中单元测试将以自动化模式执行。但是，每个系统都是为特定的目的而设置的，因此有一组特定的授权和特征。

我在这里要说的是，并不是所有的系统都会在数据库中有所需的数据类型。并非所有系统都有读/写数据库的权限。并非所有系统都具有访问文件系统或与通信系统和web服务交互的权限。如果我们依赖文档来执行单元测试，这些就是我们面临的一些问题。而且，如果与文档交互，单元就不再是孤立的，单元测试的本质就丢失了

有时系统会被刷新或者数据库中的数据被修改，因此所需类型的测试数据就不再可用。突然你的单元测试开始失败，然后你就一直在想为什么！！

以下是我们在测试访问文档的CUT时通常面临的困难：

所需的文档可能不适用于所有系统。系统刷新时，文档中的修改可能也是一个关注点。即使文档可用，大数据定义，访问它们的授权也可能不可用。由于不同系统的定制不同，单元测试不会返回一致的结果。另外，一个测试用例可能会修改数据库中的数据，这可能会在执行其他测试用例时产生问题。这在测试用例之间产生了不必要的依赖和干扰。如果单元测试由于上述任何一个问题而失败，那么很难判断实际问题是在CUT、单元测试、定制、测试数据还是其他地方CD视图标准SAP功能模块另一个网络文件系统另一个单元测试环境配置文件

请记住，当您冒险离开LTC或访问其他UTM时，您的测试不再是单元测试，因为依赖关系已经创建。

我们需要做一些限制CUT访问文档的操作。显然，我们不能修改剪切中的代码行来删除这种交互。所以，我们需要在LTC中处理这个问题。如果我们将CUT的访问重新定向到一个模拟的文档，而不是实际的文档呢？

想象一下现实生活中的情形。

你想买一套房子，你就去看看你感兴趣的房子。现在，让我们假设实际的单位是不提供给你看。可能是因为公寓还在建设中，或者正在进行一些维修工作。也可能有其他一些这样的原因。

现在，我想让你开始把这个和我们的单元测试场景联系起来。在这种情况下，代理人/房主怎么办？他/她会带你去看同一套公寓的另一套房子（可能是样板房），它的特征和你感兴趣的一模一样。所以，返利模式，现在你要看看这套房子，决定你的交易。

我希望你有一个伟大的时间阅读上述情况！！类似地，对于单元测试，我们创建一个DOC的伪制品（例如，一个数据库对象）。我们创建了一个测试环境，使CUT能够访问这个虚拟对象，而不是实际对象。

假设我们试图访问的文档是一个数据库表。

实际上，数据库表的虚拟对象的行为与实际对象相似，其优点是，这些虚拟表的数据是在LTC本身中本地定义的，它们的结构和键与实际表的结构和键完全相同。数据库对象的这个虚拟/模拟被称为"Test Double"。

图2：使用测试夹具访问Test Double而不是DOC

请记住Test Double的行为不必与真正的DOC完全相同。它只需要提供与真实的接口相同的接口（相同的接触点），以便CUT认为它是真实的接口。因此，test double与Open SQL语句具有相同的名称、相同的结构、相同的键和相同的联系点。

根据您使用的文档，有一些方法可以将CUT的依赖关系指向test double，而不是实际的文档。

要在ABAP中执行CRUD操作，我们使用Open SQL（OSQL）。OSQL的主要改进之一是代码下推功能。OSQL语句的逻辑执行发生在数据库层而不是应用层。

这里需要一个框架来实现数据库层的依赖注入。需要在数据库中为OSQL语句的文档创建双重测试。原始的依赖关系将被删除。