数据驱动的分配单元测试¶

改进我们使用数据驱动的测试格式进行详细的角色分配测试的能力，而不是使用大量的函数调用。

问题描述¶

在许多方面，keystone 的核心功能是存储并提供对 keystone 理解的工件（即项目、域）上角色分配的访问。随着 keystone 部署规模的扩大，我们不断增加对分配访问的更高级支持，并将更多的智能推送到驱动程序中以提高效率（例如，过滤）。继承和项目层次结构只会使情况变得更加复杂。随着我们扩展此功能，分配引擎的核心复杂性实际上归结为列出角色分配的方法。这个单一的后端方法将被用于各种用途（CRUD API 响应、令牌生成、联合映射等）。

鉴于此支持的重要性，我们需要确保我们的单元测试能够跟上。过去，我们编写单元测试只是简单地编写页面上的方法调用到后端，但考虑到现在支持的众多过滤选项和场景，这变得笨拙且难以理解和维护。

如果我们有一种更简洁、一目了然的方法来编写该领域所需的增加的测试，那将是首选。

提议的变更¶

虽然我们可以直接着手解决问题并编写一个完整的自然语言测试引擎，但建议我们使用一个简单的数据驱动字典方法来定义测试计划。例如，一个非常简单的测试计划可能是

test_plan = {
    'entities': {'domain': [{'contents': {'user': 1, 'group': 1,
                                          'project': 1}}],
                 'role': 2},
    'assignments': [{'user': 0, 'role': 0, 'domain': 0},
                    {'user': 0, 'role': 1, 'project': 0}],
    'tests': [
        {'params': {},
         'results': [{'user': 0, 'role': 0, 'domain': 0},
                     {'user': 0, 'role': 1, 'project': 0}]},
        {'params': {'role': 1},
         'results': [{'user': 0, 'role': 1, 'project': 0}]}
    ]
}

以上说明

创建一个域实体，其中包含 1 个用户、组和项目。还创建 2 个角色。所有创建的实体都可以通过索引引用，该索引从零开始，并按测试计划中出现的顺序递增
创建 2 个分配，即赋予用户 0 在域 0 上具有角色 0，并赋予同一用户在项目 0 上具有角色 1。
运行两个列出角色分配测试（通过调用分配管理器调用 list_role_assignments），第一个测试不带任何参数，并检查它是否返回正确的两个分配，第二个测试传递一个过滤器，仅返回具有角色索引 1 的分配。

驱动上述测试计划的测试助手显然会将实体索引转换为实际的实体 ID，以便调用实际的驱动程序方法。

实际上，在 Kilo 周期中，已经发布了上述测试计划格式和助手的实现，作为一系列补丁来支持将列表分配方法上的过滤迁移到后端。最终，我们将此支持推迟到 Liberty，现在是时候决定我们想要针对此功能的测试类型了。

以下 Kilo 补丁增加了对这种数据驱动方法的越来越多的支持，并且在开发新的列表角色分配后端方法期间发现了许多缺陷。显然，需要类似的东西。

https://review.openstack.org/#/c/149178/ https://review.openstack.org/#/c/151623/ https://review.openstack.org/#/c/151962/ https://review.openstack.org/#/c/154302/ https://review.openstack.org/#/c/153897/ https://review.openstack.org/#/c/154485/

以上补丁实现了添加对

使用现有实体
“有效模式”在列出角色分配中
组
继承和项目层次结构

备选方案¶

如上所述，我们可以编写一个更复杂的自然语言处理器测试系统 - 但由于这是一个用于内部开发的测试工具，我们需要平衡工具中的代码量与它所取代的测试量。这里有两个问题。首先，我们理想情况下不希望有一个过于复杂的测试助手，以至于它本身也需要进行测试。其次，我们应该注意性能。作为一种纯粹的数据定义测试方法，当前的提议实际上是直接从提供的数据创建一组定向循环。这通常是测试人员手动执行的操作 - 因此，这种方法对测试性能的影响应该很小。需要更多处理测试计划才能将其转换为管理器调用的解决方案可能会对性能产生更大的影响。

我们也可以使测试计划更通用 - 例如，也许还有其他后端方法我们也想应用它。建议我们解决手头的问题，然后在未来考虑任何此类更改。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

由于我们基本上使用字典来驱动一组定向循环，因此运行测试的性能影响应该最小。

其他部署者影响¶

无

开发人员影响¶

无

实现¶

负责人¶

主要负责人: henry-nash

工作项¶

以上代码已经编写完毕，所以我们只需要重新合并它即可。

依赖项¶

无

测试¶

无

文档影响¶

无

参考资料¶

无

基于数据的分配单元测试