How to use yml file in my cucumber test? - cucumber

I want to use config.yml file in my cucumber-test. I whrite such like this:
test_config.yml:
group_name: animals
learn_group_name: dogs
card_box_name: cats
cucumber_test.rb:
require `watir-webdriver`
require `yaml`
def read_config
config = YAML.load(File.read(`/home/profile/Desktop/cucumber/test_config.yml`))
#group = config[`group_name`]
#learn_group = config[`learn_group_name`]
#card_box = config[`card_box_name`]
end
puts `Group = #{#group}`
puts `Learn group = #{#learn_group}`
puts `Card box = #{#card_box}`
...
in console (terminal):
Group =
Learn group =
Card box =
...
But what is wrong?

This is a really bad code example.
You are you using backticks (`) instead of quotes ("). That will cause problems. A lot of problems.
The problem is not related to cucumber or watir-webdriver gems. You are defining instance variables (#group...) in a method (read_config) but then you are never calling the method.
Please update the question with more realistic example.

Before do
#host ||= YML["host"]
#group_name_for_search ||= YML["group_name_for_search"]
#learn_group_name_for_search ||= YML["learn_group_name_for_search"]
#card_box_name_for_search ||= YML['card_box_name_for_search']
end
I must to define, before the cucumber steps, Before do.

Related

pass options to cucumber formatter

When running cucumber to perform the test scenario's for a project, I use the pretty formatter cucumber --format pretty.
This gives me output like
#search
Feature: search
Background: # features/zoeken.feature:4
Given I log in as testuser # features/step_definitions/elvis_steps.rb:1
I would like the formatter to skip the mention of the sourceline. In the code of the pretty-formatter, I located the place where it is output and is says
def print_step_data(test_step, result)
base_indent = options[:expand] && in_scenario_outline ? 8 : 4
step_keyword = test_step_keyword(test_step)
indent = options[:source] ? #source_indent - step_keyword.length - test_step.text.length - base_indent : nil
print_comments(test_step.location.lines.max, base_indent)
name_to_report = format_step(step_keyword, #step_matches.fetch(test_step.to_s) { NoStepMatch.new(test_step, test_step.text) }, result.to_sym, indent)
#io.puts(indent(name_to_report, base_indent))
print_multiline_argument(test_step, result, base_indent + 2) unless options[:no_multiline]
#io.flush
end
So I can get the output I want bij setting option :source to false. Which indeed works.
My question is: how can I pass this option to the formatter without changing the code of the formatter? Is there a command line trick for this, or can I specify it in my own code?
Result of adding options[:source] = false to pretty.rb:
#search
Feature: search
Background:
Given I log in as testuser
.... which is what I want.

how to go around "keyword can't be an expression" when updating in sqlalchemy?

i have a following statement:
conn = engine.connect()
conn.execute(Somedatabase.update().where(somecriteria==somecriteriavalue).values(name = somevalue))
and it works, but when i try replace it by following:
D={1: "name"}
print(D[1])
conn.execute(Somedatabase.update().where(somecriteria==somecriteriavalue).values(D[1]) = somevalue))
Then, I got an error: "keyword can't be an expression". How can I go around to be able use it in cycle?
So far i figured only
text="conn.execute(Somedatabase.update().where(somecriteria == somecriteriavalue).values("+(D[1])+" = \"somevalue\"))"
eval(text)
But i would prefer to not using eval.
I believe you can use a dictionary as a parameter for values:
D={1: "name"}
print(D[1])
conn.execute(
Somedatabase.update().where(
somecriteria==somecriteriavalue
).values({
D[1]: somevalue,
})
)
https://docs.sqlalchemy.org/en/13/core/dml.html#sqlalchemy.sql.expression.ValuesBase.values

Setting the current test insertion within the DUT model

We have evolved our Origen usage such that we have a params file and a flow file for each test module (scan, mbist, etc.). We are now at the point where we need to take into account the test insertion when handling the DUT model and the test flow generation. I can see here that using a job flag is the preferred method for specifying test insertion specifics into the flow file. And this video shows how to specify a test insertion when simulating the test flow. My question is how can a test insertion be specified when not generating a flow, only loading params files into the DUT model? Take this parameter set that defines some test conditions for a scan/ATPG test module.
scan.define_params :test_flows do |p|
p.flows.ws1.chain = [:vmin, :vmax]
p.flows.ft1.chain = [:vmin, :vmax]
p.flows.ws1.logic = [:vmin, :vmax]
p.flows.ft1.logic = [:vmin]
p.flows.ws1.delay = [:pmax]
p.flows.ft1.delay = [:pmin]
end
You can see in the parameter set hierarchy that there are two test insertions defined: 'ws1' and 'ft1'. Am I right to assume that the --job option only sets a flag somewhere when used with the origen testers:run command? Or can this option be applied to origen i, such that just loading some parameter sets will have access to the job selected?
thx
There's no built-in way to do what you want here, but given that you are using parameters in this example the way I would do it would be to align your parameter contexts to the job name:
scan.define_params :ws1 do |p|
p.flows.chain = [:vmin, :vmax]
p.flows.logic = [:vmin, :vmax]
p.flows.delay = [:pmax]
end
scan.define_params :ft1 do |p|
p.flows.chain = [:vmin, :vmax]
p.flows.logic = [:vmin]
p.flows.delay = [:pmin]
end
There are various ways to actually set the current context, one way would be to have a target setup per job:
# target/ws1.rb
MyDUT.new
dut.params = :ws1
# target/ft1.rb
MyDUT.new
dut.params = :ft1
Here it is assuming that the scan object is configured to track the context of the top-level DUT - http://origen-sdk.org/origen//guides/models/parameters/#Tracking_the_Context_of_Another_Object

Parameter aliasing

when implementing Origen::Parameters, I understood the importance of defining a 'default' set. But, in essence, my real default is named something different. So I implemented a hack of a parameter alias:
Origen.top_level.define_params :default do |params|
params.tconds.override = 1
params.tconds.override_lev_equ_set = 1
params.tconds.override_lev_spec_set = 1
params.tconds.override_levset = 1
params.tconds.override_seqlbl = 'my_pattern'
params.tconds.override_testf = 'tm_3'
params.tconds.override_tim_spec_set = 'bist_xxMhz'
params.tconds.override_timset = '1,1,1,1,1,1,1,1'
params.tconds.site_control = 'parallel:'
params.tconds.site_match = 2
end
Origen.top_level.define_params :cpu_mbist_hr, inherit: :default do |params|
# way of aliasing parameter names
end
Is there a proper method of parameter aliasing that is just not documented?
There is no other way to do this currently, though I would be open to a PR to enable something like:
default_params = :cpu_mbist_hr
If you don't want them to be called :default in this case though, then maybe you don't really want them to be the default anyway.
e.g. adding this immediately after you define them would effectively give you an alternative default and would do pretty much the same job as the proposed API above:
# self is required here to help Ruby know that you are calling the params= API
# and not defining a local variable called params
self.params = :cpu_mbist_hr

SOAP::Lite - clients using version 1.1 and 1.2 threaded in mod_perl

I have several SOAP::Lite clients running under mod_perl in Apache hhtpd.
Some of them use 1.1 soap-servers and some of them use 1.2 servers. So I have code like:
# In client 1:
my $soap1 = SOAP::Lite->soapversion("1.1");
$result1 = $soap1->method1();
# In client 2:
my $soap2 = SOAP::Lite->soapversion("1.2");
$result2 = $soap2->method2();
This works in stand-alone clients, but when I run the code under mod_perl, I seem to get stung by that the soapversion
method has side-effects:
# From SOAP::Lite.pm
sub soapversion {
my $self = shift;
my $version = shift or return $SOAP::Constants::SOAP_VERSION;
($version) = grep {
$SOAP::Constants::SOAP_VERSIONS{$_}->{NS_ENV} eq $version
} keys %SOAP::Constants::SOAP_VERSIONS
unless exists $SOAP::Constants::SOAP_VERSIONS{$version};
die qq!$SOAP::Constants::WRONG_VERSION Supported versions:\n#{[
join "\n", map {" $_ ($SOAP::Constants::SOAP_VERSIONS{$_}->{NS_ENV})"} keys %SOAP::Constants::SOAP_VERSIONS
]}\n!
unless defined($version) && defined(my $def = $SOAP::Constants::SOAP_VERSIONS{$version});
foreach (keys %$def) {
eval "\$SOAP::Constants::$_ = '$SOAP::Constants::SOAP_VERSIONS{$version}->{$_}'";
}
$SOAP::Constants::SOAP_VERSION = $version;
return $self;
}
This is what I believe happens:
Basically, the soapversion call rededefines essential constants in $SOAP::Constants. And since this is mod_perl, the $SOAP::Constants are global and shared between every server-thread (I believe. Please correct me if I'm wrong). This leads to a race-condition: Most of the times, the codelines gets executed more-or-less in the sequence seen above. But once in at while (actually about 2% of the calls) the execution sequence is:
Thread1: my $soap1 = SOAP::Lite->soapversion("1.1");
Thread2: my $soap2 = SOAP::Lite->soapversion("1.2");
Thread1: $result1 = $soap1->method1();
Thread2: $result2 = $soap2->method2();
And so, the $soap1->method1() gets called with $SOAP::Constants set as befitting version 1.2 - causing several namespace to be wrong, notably:
xmlns:soapenc="http://www.w3.org/2003/05/soap-encoding"
Which is wrong for 1.1 - who prefers:
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
If I could somehow make $SOAP::Constants localized to a serverthread or something like that, I guess things would be fine. But any solution will be appreciated.
Run Apache with the prefork model instead of the threading model (mpm_prefork_module instead of mpm_event_module or mpm_worker_module), so that each Apache child will have its own Perl interpreter, hence its own set of constants.
Otherwise have a look on the modperl documentation regarding the PerlOptions directive, specifically the clone and/or parent value. But stop using threads seem simpler to me, threads and Perl were never friends.

Resources