Any way to change desired capability for certain test cases - python-3.x

I don't know, is it valid question or not, but I need to know that can we change desired capability for certain test cases, such as my desired capabilities are like this:
desired_caps = dict(
platformName="Android",
platformVersion="12",
deviceName="testing_device_001",
automationName="UiAutomator2",
appPackage="app_package_name",
appActivity="its_activity",
noReset=True
)
I need to change 'noReset' value to 'False' for certain test cases?
Is it possible?
and above all, does it considered as good practice?

Related

Is there an equivalent OR logic based from a Variable value in Origen?

I am working on Verigy 93K test program and I have a logic that I would like to know if there's an equivalent code in Origen.
I am working on Verigy 93K test program and I have this logic (IF condition) that I need to insert in my flow.
Basically, I have a variable called 'INSERTION' and this will have different values like 'GCORR', 'VCORR' and others.
I would like to know if there's an equivalent code like this in Origen.
I attached a snapshot, hope that it can help clarify my question more.
In this logic, I would like to check the INSERTION value and if the value is not equal to GCORR or VCORR, the logic should pass, else, fail.
Here is the screenshot:
This pull-request adds an official API for this.
This example would be implemented as:
whenever_any ne(:INSERTION, 'GCORR'), ne(:INSERTION, 'VCORR') do
# Your tests in here
end
That would produce something logically equivalent and which can be re-targeted to other platforms.
If you don't care about that and want to produce exactly as you have it in the above example, then this should work too (where the OR is hard-coded for V93K syntax):
whenever ne(:INSERTION, 'GCORR|VCORR') do
# Your tests in here
end
Here is the preliminary documentation of this feature from the above PR - https://github.com/Origen-SDK/origen_testers/blob/66345c9422d9fa6b2577af20110259e45c2bdd26/templates/origen_guides/program/flowapi.md.erb#L71
I couldn't find api support on flow control or variable values beyond "if/unless_enable" support which can help check for 1 or zero. One way is to use render.
render 'if #INSERTION != "GCORR|VCORR" then'
render '{'
# your code for non-GCORR_VCORR flow
render "} \n else \n { \n } "

Taking input from user in scheme

I want to get input in scheme and after that I want to use these numbers for checking etc How can I do it?
And also I can take random numbers but I can't check them
I want to get input in scheme
I think you will probably want to use read for that: https://docs.racket-lang.org/reference/Reading.html#%28def.%28%28quote.~23~25kernel%29._read%29%29
I want to use these numbers for checking etc
What do you mean checking? like comparing? First you will need a variable, let works for most things but perhaps you will want something else in some cases. Let your google-fu help you.
(let ((x some-expr))
; code block that uses x
Then you do whatever "checking" you want like you would with anything else like to see if two strings are the same length and contain the same characters in the same (relative) positions:
(string=? "PIE" "PIE")
Always with scheme i'd check the (in my opinion) great documentation first: http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/

How to use SWRL rules on Protegé 4.3 using Pellet

I've just started doing work on ontologies with Protegé and I'm trying to understand how to use SWRL rules. I'm afraid I don't get the concept or how to correctly treat them, as I'm not able to produce any output. I'll explain a bit more a simple case I created to test this:
I've created three individuals, called A, B and C. Each one with a test property, that has a boolean range. On the property assertions tab of each one I've initialized their values, so they are test(A,true), test(B,true) and test(C,true). To test how rules work, I created a rule like this: test(A,true), test(B,true) -> test(C,false). The way I understand it is that, if A and B's test property is true, C's one would turn false. To do so, I start the reasoner (Pellet) but nothing happens. I mean, it says the reasoner is active and no "inconsistent ontology" messages appear, but C's test value doesn't change. I'm sure this must be a really simple confusion but I can't seem to find it anywhere nor check if the rule has been activated.
Thank you in advance.
The inference doesnt work like that, you cannot retract test(C, true) if you've asserted it. Your ontology probably includes both test(C, true) and test(C, false) which is completely legal unless you've specified otherwise; in which case then you'd see the inconsistency.

Capybara: Should I get rid of extracted constants or keep them?

I was wondering about some best practices regarding extraction of selectors to constants. As a general rule, it is usually recommended to extract magic numbers and string literals to constants so they can be reused, but I am not sure if this is really a good approach when dealing with selectors in Capybara.
At the moment, I have a file called "selectors.rb" which contains the selectors that I use. Here is part of it:
SELECTORS = {
checkout: {
checkbox_agreement: 'input#agreement-1',
input_billing_city: 'input#billing\:city',
input_billing_company: 'input#billing\:company',
input_billing_country: 'input#billing\:country_id',
input_billing_firstname: 'input#billing\:firstname',
input_billing_lastname: 'input#billing\:lastname',
input_billing_postcode: 'input#billing\:postcode',
input_billing_region: 'input#billing\:region_id',
input_billing_street1: 'input#billing\:street1',
....
}
In theory, I put my selectors in this file, and then I could do something like this:
find(SELECTORS[:checkout][:input_billing_city]).click
There are several problems with this:
If I want to know the selector that is used, I have to look it up
If I change the name in selectors.rb, I could forget to change it somewhere else in the file which will result in find(nil).click
With the example above, I can't use this selector with fill_in(SELECTORS[:checkout][:input_billing_city]), because it requires an ID, name or label
There are probably a few more problems with that, so I am considering to get rid of the constants. Has anyone been in a similar spot? What is a good way to deal with this situation?
Someone mentioned the SitePrism gem to me: https://github.com/natritmeyer/site_prism
A Page Object Model DSL for Capybara
SitePrism gives you a simple, clean and semantic DSL for describing
your site using the Page Object Model pattern, for use with Capybara
in automated acceptance testing.
It is very helpful in that regard and I have adjusted my code accordingly.

automapper - simplest option to only write to destination property if the source property is different?

NOTE: The scenario is using 2 entity framework models to sync data between 2 databases, but I'd imagine this is applicable to other scenarios. One could try tackling this on the EF side as well (like in this SO question) but I wanted to see if AutoMapper could handle it out-of-the-box
I'm trying to figure out if AutoMapper can (easily :) compare the source and dest values (when using it to sync to an existing object) and do the copy only if the values are different (based on Equals by default, potentially passing in a Func, like if I decided to do String.Equals with StringComparison.OrdinalIgnoreCase for some particular pair of values). At least for my scenario, I'm fine if it's restricted to just the TSource == TDest case (I'll be syncing over int's, string's, etc, so I don't think I'll need any type converters involved)
Looking through the samples and tests, the closest thing seems to be conditional mapping (src\UnitTests\ConditionalMapping.cs), and I would use the Condition overload that takes the Func (since the other overload isn't sufficient, as we need the dest information too). That certainly looks on the surface like it would work fine (I haven't actually used it yet), but I would end up with specifying this for every member (although I'm guessing I could define a small number of actions/methods and at least reuse them instead of having N different lambdas).
Is this the simplest available route (outside of changing AutoMapper) for getting a 'only copy if source and dest values are different' or is there another way I'm not seeing? If it is the simplest route, has this already been done before elsewhere? It certainly feels like I'm likely reinventing a wheel here. :)
Chuck Norris (formerly known as Omu? :) already answered this, but via comments, so just answering and accepting to repeat what he said.
#James Manning you would have to inherit ConventionInjection, override
the Match method and write there return c.SourceProp.Name =
c.TargetProp.Name && c.SourceProp.Value != c.TargetProp.Value and
after use it target.InjectFrom(source);
In my particular case, since I had a couple of other needs for it anyway, I just customized the EF4 code generation to include the check for whether the new value is the same as the current value (for scalars) which takes care of the issue with doing a 'conditional' copy - now I can use Automapper or ValueInject or whatever as-is. :)
For anyone interested in the change, when you get the default *.tt file, the simplest way to make this change (at least that I could tell) was to find the 2 lines like:
if (ef.IsKey(primitiveProperty))
and change both to be something like:
if (ef.IsKey(primitiveProperty) || true) // we always want the setter to include checking for the target value already being set

Resources