我已经开始为我们的测试块和帮助程序开发一些规范/示例测试,并且我希望能够跨多个测试人员运行。我没有在测试期间看到任何用于设置测试仪的显式API。我在OrigenTesters
规范中看到我们可以做类似的事情:
Origen.environment.temporary = 'j750.rb'
Origen.load_target('default')
工作正常,并不是那么糟糕,但是有某种语法,如:
Origen.with_tester('j750.rb')
# do whatever with this tester
end
或者只是
Origen.switch_tester('j750.rb')
Origen.tester = OrigenTesters::J750.new
# or something to these effects
由于
答案 0 :(得分:1)
更改目标是更改DUT和Tester实例的机制,因此从根本上说,在第一个示例中完成它的方式是正确的。
我认为你现在可以动态实例化一个新的测试人员,但这不是真正的设计而不是我想要鼓励的模式。事实上,我们最近有类似的错误案例,因为目标/环境组合实例化了两个不同的测试人员。 因此,在将来,我希望看到实例化第二个测试人员引发错误的方式与您今天尝试实例化第二个DUT对象的方式相同。 顺便说一句,这不只是一个品味问题,注册/取消注册当前运行时以监听回调等事情还有很多工作,如果我们限制,它更容易管理和推理可以将DUT和Tester更改为目标加载事件的时间。
我认为Configurable Targets大概是你想要的,从API的角度来看这看起来很干净:
# target/my_test_target.rb
options[:tester].new
MyDUT.new
然后在你的测试代码中:
Origen.load_target('my_test_target', tester: OrigenTesters::V93K)
tester.v93k? # => true
tester.j750? # => false
Origen.load_target('my_test_target', tester: OrigenTesters::J750)
tester.v93k? # => false
tester.j750? # => true
这里有一个弱点:以这种方式编程操作目标的API并没有真正跟上这样一个事实,即一个约定已经演变为在环境中加载Tester并在目标中加载DUT。 p>
我们肯定希望继续强制执行加载目标或环境始终意味着两者都被加载。但是,我们可能也应该引入可配置环境的概念:
# environment/configurable.rb
options[:tester].new
然后在你的测试代码中:
# Calling this would re-load the current target as well
Origen.load_environment('configurable', tester: OrigenTesters::V93K)
tester.v93k? # => true
tester.j750? # => false
Origen.load_environment('configurable', tester: OrigenTesters::J750)
tester.v93k? # => false
tester.j750? # => true
但是,在撰写本文时,尚未支持该API。