This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
实现 Cinder V2 API 测试¶
https://blueprints.launchpad.net/tempest/+spec/cinder-v2-api-tests
通过共享服务客户端和测试代码,实现 Cinder v2 API 测试与 v1 的兼容。
问题描述¶
Tempest 目前缺乏足够的 Cinder v2 api 测试。我们需要为它添加更多测试。Cinder v2 api 只有一些小的更新,因此 v1 和 v2 测试可以共享服务客户端和测试代码。 这样,我们就不需要维护大量的重复测试代码。
提议的变更¶
此蓝图建议 Cinder v1 和 v2 测试共享服务客户端和测试代码。它包括以下更改
创建通用的服务客户端
创建通用的基础测试类
使每个 v1 测试类继承 v2 测试类
更改 Cinder API 测试目录结构
1. 创建通用的服务客户端¶
v1 和 v2 服务客户端只有很小的差异。大部分代码应该相同。因此,我们可以创建一个通用的服务客户端,并让 v1 和 v2 继承它。
[v1 服务客户端] -> [CommonServiceClient]
[v2 服务客户端] -> [CommonServiceClient]
2. 创建通用的基础测试类¶
现在,每个 Cinder API 测试类都继承如下:
[v1 测试类] -> [BaseVolumeV1Test] -> [BaseVolumeTest]
[v2 测试类] -> [BaseVolumeV2Test] -> [BaseVolumeTest]
为了共享 API 测试类,我们需要创建通用的基础测试类,而不是 BaseVolumeV1Test/BaseVolumeV2Test。类实例可以根据某个变量(该变量代表 API 版本)来切换其行为。应用此通用类到每个 API 测试类后,可以删除现有的 BaseVolumeV1Test 和 BaseVolumeV2Test。
3. 使每个 v1 测试类继承 v2 测试类¶
我们需要更改 v2 测试类的继承关系为通用基础测试类,并更改 v1 测试类的继承关系为 v2 测试类
[v1 测试类] -> [v2 测试类] -> [CommonVolumeTest]
在 v1 测试类中,代表 API 版本的变量应为“1”,在 v2 测试类中该变量应为“2”
class SomeApiV2Test(CommonVolumeTest):
_api_version = 2
[..]
class SomeApiV1Test(SomeApiV2Test):
_api_version = 1
[..]
4. 更改 Cinder API 测试目录结构¶
当前的测试目录结构是:
tempest/api/volume/ : v1 API 测试文件
tempest/api/volume/v2/ : v2 API 测试文件
这种结构不易理解,最好将 v1 API 测试文件移动到某个明确显示 v1 的目录中。
此蓝图建议将结构更改为:
tempest/api/volume/ : 通用测试文件
tempest/api/volume/v1/ : v1 API 特定的测试文件
tempest/api/volume/v2/ : v2 API 特定的测试文件
可以在“tempest/api/volume/”中存储 v1 和 v2 之间可以共享代码的测试用例。对于没有共享代码的特定测试用例,(3) 中的继承模型将不起作用。层级结构将为:
[v1 测试类] -> [CommonVolumeTest]
[v2 测试类] -> [CommonVolumeTest]
这些测试文件将存储在:
tempest/api/volume/v1/
tempest/api/volume/v2/
实现¶
负责人¶
- 主要负责人
Zhi Kun Liu <liuzhikun@gmail.com>
- 其他贡献者
Chandan Kumar <chkumar246@gmail.com> jun xie <junxiebj@cn.ibm.com>
里程碑¶
- 完成目标里程碑
Juno-2
工作项¶
添加 v1 和 v2 的通用服务客户端
添加 Cinder v1/v2 API 测试的通用类
添加 Cinder v1/v2 API 测试的通用管理类
使用新的共享测试类添加新的测试用例 使用 Google Docs 电子表格来管理任务进度:(cinder_v2_api_tests)