我一直在查看流程代码,以便更直接地控制93k测试节点上的通过/失败分支。我们可以在origen-testers的93k输出端添加额外的钩子,但是我们冒险打破平台不可知论。
相反,我相信如果我们能够更直接地影响ATP数据结构的构建方式,那么已经存在的测试人员输出驱动程序将会正确处理它。 ATP支持:on_pass和:on_fail键,但它目前似乎只支持放入这些块的bin。
我想做的就是写一个这样的流程:
func :test1, param1_key: param1_value, on_pass: do
func :test2, param2_key: param2_value
end, on_fail: do
func :test3, param3_key: param3_value
bin 10
end
我意识到我可以用流量控制变量做到这一点,但是如果有很多测试需要这种类型的结构导致大量的测试ID和流量控制变量。能够直接说出通过和失败路径中的测试将大大简化流程。它自然也会导致嵌套的能力,例如,如果上面的test2需要传递和失败路径。
我还在学习ruby,但我意识到上面的代码会抛出编译错误。我相信我们可以在流构建器中使用lambdas进行一点递归来完成这样的事情:
func :test1, param1_key: param1_value, on_pass: ->{
func :test2, param2_key: param2_value
}, on_fail: ->{
func :test3, param3_key: param3_value
bin 10
}
是否已有办法更直接地控制或影响内部ATP流量数据结构?如果没有,我们可以将以上内容添加到增强请求列表中吗?
答案 0 :(得分:1)
我并不反对这种语法建议,但这是使用当前可用的API进行编码的方式:
2
这也完全支持嵌套:
$api = new Client([
'base_uri' => 'http://celestrak.com',
]);
$response = $api->get('jsonlocater');
$data = json_decode($response->getBody()->getContents(), true);
foreach ($data as $attributes) {
$attributes = array_change_key_case($attributes, CASE_LOWER);
Satellites::create($attributes);
}
添加对传递给func :test1, param1_key: param1_value, id: :t1
if_passed :t1 do
func :test2, param2_key: param2_value
end
if_failed :t1 do
func :test3, param3_key: param3_value
bin 10
end
和func :test1, param1_key: param1_value, id: :t1
if_passed :t1 do
func :test2, param2_key: param2_value, id: :t2
if_failed :t2 do
func :test4
end
end
if_failed :t1 do
func :test3, param3_key: param3_value
bin 10
end
的块/ lambda的支持可能并不像您想象的那么容易实现。例如它应该直接映射到V93K,但是在Teradyne上我们需要将它全部展平并生成标志,因为它不提供相应的可嵌套IF结构。
我认为这个Origen源代码非常易读且不含糊,这正是我们在该级别上所追求的目标。理想情况下,我们希望非技术利益相关者甚至可以读取流程代码,以便它可以作为流程的文档。
我认为你真正想要解决的问题是,这将产生目前并不真正需要的流量控制变量,但它们很快就会消失。 我们采用的方法是使用元数据助手(如流量变量)生成内部低级实现,这使得很容易针对Teradyne,与V93K相比,它提供的流量控制能力要小得多。
然后对于93K或其他提供类似C类流控制API的平台,编译器将对内部表示运行一些优化,以在最终渲染之前去除冗余标志结构。
下一轮优化的工作已经开始,请关注此拉取请求 - https://github.com/Origen-SDK/origen_testers/pull/52。我将添加一些额外的测试用例,例如这里提到的测试用例,以确保不必要的标记得到优化。
如果您遵循上面的编码指南,它将生成一个逻辑上正确的测试程序,然后在几周内您可以更新到新版本的OrigenTesters,输出将变得更漂亮。