I am using the load_target in my specs testing as so:
describe "MBIST Test Module" do
before :all do
Origen.app.unload_target!
Origen.load_target 'prod_a0'
end
And I see the load_target method accepts an optional options hash. However, when I use it like shown below, I do not see the options being applied to the initialization options hash. Is this expected behavior?
describe "MBIST Test Module" do
before :all do
Origen.app.unload_target!
Origen.load_target 'prod_a0', force_import: true
end
thx
Such options are not passed automatically into the initialization of the DUT model, but rather they are available within the scope of the target file, this is described in this section of the docs - https://origen-sdk.org/origen/guides/runtime/programming/#Configurable_Targets
If you want them to be available within your DUT initialization, you can simply pass them through:
# target/my_dut.rb
MyApp::MyDut.new(options)
Related
The documentation for --frozen-intrinsics says:
Only the root context is supported. There is no guarantee that globalThis.Array is indeed the default intrinsic reference. Code may break under this flag
I couldn't understand this. Can someone help me understand this in simple words with an example?
Background: I was checking nicolo-ribaudo/jest-light-runner where there is a mention of --frozen-intrinsics.
When you use --frozen-intrinsics, all the built-in JavaScript objects and functions are recursively frozen, except for globalThis.
If you run node --frozen-intrinsics, you can check it:
> Object.isFrozen(Array)
true
> Object.isFrozen(Array.prototype)
true
> Object.isFrozen(globalThis);
false
> Array.isArray = () => true; Array.isArray(2); // you cannot modify built-in properties, this will not return true
false
> globalThis.foo = 3; foo; // you can still define new globals
3
> globalThis.Array = 4; Array; // However, you can also replace existing globals
4
This prevents your code from accidentally modifying globals, so I recommended it in jest-light-runner to prevent tests from accidentally influencing each other (since it doesn't isolate test files like Jest's default runner does).
Note that you still have a communication channel by attaching new properties to the global object, so it's not an isolation mechanism.
Now, lets take a look at the docs you quoted.
Only the root context is supported.
In Node.js, you can create multiple "global contexts" using the vm built-in module. --frozen-intrinsics does not affect those contexts, so if you run node with --frozen-intrinsics:
> Object.isFrozen(Array)
true
> Object.isFrozen(require("vm").runInNewContext("Array"))
false
There is no guarantee that globalThis.Array is indeed the default intrinsic reference.
As mentioned earlier, globalThis.Array could still be replaced. However, if you have a "safe reference" to an object (either using syntax, or by storing the original Array global in a local variable), you can be sure that it's not modified:
let OriginalArray = Array;
require("untrusted-module");
globalThis.Array; // this might have been replaces
[].push; // this is still the original one
OriginalArray.isArray; // this is still the original one
Code may break under this flag
If code needs to modify built-ins, it would obviously stop working. For example, you cannot use polyfills that modify the global objects.
I have a gem that supports two different libraries with a generic DUT model:
module MyGemLibrary
module RSpec
class DUT
include Origen::TopLevel
attr_accessor :force_import, :nick, :revision
def initialize(options = {})
options = {
force_import: false,
nick: :rspec,
revision: :a0
}.update(options)
#force_import = options[:force_import]
#nick = options[:nick]
#revision = options[:revision]
end
end
end
end
I have two rspec files:
myserver:ondie_devices $ ls spec
ringosc_spec.rb spec_helper.rb testtrans_spec.rb
What is the best known method for initializing the DUT and closing the DUT in each spec file? When I used a local variable to store the DUT I got this error:
myserver:ondie_devices $ origen specs
[INFO] 0.010[0.010] || OndieDevices: Loading ringosc model
Attempt to set an instance of OndieDevices::RSpec::DUT as the top level when there is already an instance of OndieDevices::RSpec::DUT defined as the top-level!
I have seen various ways of dong this but none seem to accomplish what I need done:
prevent the error above
Ensure Origen.top_level is initialized correctly such that theinstance attributes are readily available from within the gem code library. E.G.
An error occurred while loading ./spec/ringosc_spec.rb.
Failure/Error: Pathname.new("#{tmpdir}/#{Origen.top_level.nick}_#{Origen.top_level.revision}_ringosc_#{data_type}.bin")
NoMethodError:
undefined method `nick' for nil:NilClass
You can't manually instantiate multiple top-level objects, it needs to be done within the context of a target load/change.
The easiest way to do this for spec tests is by using anonymous targets - https://origen-sdk.org/origen/guides/runtime/programming/#Anonymous_Targets
Origen.target.temporary = -> do
DUT.new
end
Origen.load_target
That will also safely un-load any existing target (and its DUT) which will resolve your issue.
It is often common to do something like the above within a before :each block to reload the target between tests, or in a before :all block to have the same target loaded for all tests in a spec file.
I have a SpringBootTest that reads in properties from application.properties. The setup code uses the #Value annotation to set the values accordingly. One of these properties is an array of names.
I am trying to write a data driven test using Spock. The where statement is using these names that are initialized in the setup:
expect:
retrievedName == value
where:
value << getNames()
This always fails with org.spockframework.runtime.SpockExecutionException: Data provider is null.
It appears that the getNames() call is invoked before the properties are initialized in the setup code. If I do not use the where statement (data driven testing), all works fine. Is there a workaround for this?
You cannot use data initialized in the setup section as a source for data driven tests. As per the docs:
Although it is declared last, the where block is evaluated before the feature method containing it runs.
You can try and use setupSpec() methods and #Shared fields as a workaround.
See here for an example.
We are dynamically creating bunches of characterization tests within our test interface. I would like to enclose them in a group for readability. I see that groups can be referenced in the flow files, is there an 'start_group' interface method where a list of tests could be added to as they are created?
thx
I think you can assign a group parameter to individual tests, which might help:
group :my_group do
test :test1
test :test2
end
# This is equivalent
test :test1, group: :my_group
test :test2, group: :my_group
Obviously the group parameter could be injected within the interface if that is preferable in your case.
Also remember that everything you can call in a flow you can call in an interface, so you could also use the group :blah do ... end approach within your interface logic.
I write module which will define new types. Inside newproperty definition I want to use custom function (also provided in this module) which will munge passed value:
Function
#lib/puppet/parser/functions/my_custom_function.rb
module Puppet::Parser::Functions
newfunction(:my_custom_function, :type => :rvalue) do |args|
...
end
end
Type
#lib/puppet/type/new_type.rb
Puppet::Type.newtype(:new_type) do
newparam(:name) do
munge do |value|
my_custom_function(value)
end
end
end
but I get undefined local variable or method when try use function in type like above.
I also don't have access to stdlib functions inside custom type, but these functions are available in manifest file.
Does someone can provide example how to execute custom function inside type definition especially in munge block?
Custom functions are parser functions, for use in your manifests only.
The type code is used by the agent only, which will not load parser functions while initializing resources.
You will have to duplicate your munging code. If this is not feasible, you may have to implement it in a custom Ruby library, and use that from both within your custom function and your type. The library will need to be installed on both masters and agents in this case.
You need to extract the code from your custom function into a separate location and then call that shared code from both your custom function and from your type/provider. You do not need to pull the code into a separate gem to do this, it is fairly easy to keep the code local to your module.
Put your own Ruby classes in the directory lib/puppet/util/ of your module. You should then be able to require 'puppet/util/my_class' from both your custom function and your type/provider. You can see an example of how I've done this in my module jboss-puppet_admin.