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.
Related
How does one convert an ASTNode (or at least a CompilationUnit) into a valid piece of source code?
The documentation says that one shouldn't use toString, but doesn't mention any alternatives:
Returns a string representation of this node suitable for debugging purposes only.
CompilationUnits have rewrite, but that one does not work for ASTs created by hand.
Formatting options would be nice to have, but I'd basically be satisfied with anything that turns arbitrary ASTNodes into semantically equivalent source code.
In JDT the normal way for AST manipulation is to start with a basic CompilationUnit and then use a rewriter to add content. Then ASTRewriteAnalyzer / ASTRewriteFormatter should take care of creating formatted source code. Creating a CU just containing a stub type declaration shouldn't be hard, so that's one option.
If that doesn't suite your needs, you may want to experiement with directly calling the internal org.eclipse.jdt.internal.core.dom.rewrite.ASTRewriteFlattener.asString(ASTNode, RewriteEventStore). If not editing existing files, you may probably ignore the events collected in the RewriteEventStore, just use the returned String.
I would like to change the behavior of menhir's output in follwoing way:
I want it to look up all grammatical alternatives if it finds any, and put them in a list and get me back this ambigouus interpretation. It shall not reduce conflicts, just store them.
In the source code of menhir, it seems to me, that I have to look in "Engine.ml". The resultant syntactically determined token comes in a variant type item "Accepted v" as a state of a checkpoint of the grammatical automaton. This content is found by a function "accept env prod" before, that is part of a bundle of recursive functions, that change the states.
Do you have a tip, how I could change these functions to put all the possible results in the list here and proceed as if nothing happened? Or do you think, that this wont work anyway?
Thanks.
What you are looking for is a GLR parser generator (G is for generalized). Menhir is not such tool, and I doubt you could modify it easily to do what you want.
However, there is another tool that does exactly what you want: dypgen.
I'm using PHPStorm EAP version PS-138.940.
I have code as follows:
Config(__NAMESPACE__."\ObjectsToIdentifiers")->oldTables = array('Modules\Old\Model\DeviceStock','Modules\Old\Model\ProductPack','Modules\Old\Model\SpareStock','Modules\Old\Model\ConsumStock');
The functionality is irrelevant in this case. Important are the entries in the array. These are fully qualified class names - the leading / is omitted, but adding it doesn't solve my problem. I want to be able to click inside one of the string literals, press Ctrl+B and be redirected to the class definition.
Note that this works in ExtJS (javascript framework) where a string literal like
"MyApp.namespace.view.MyComponent"
will take me there.
Is there any way to manually configure this or do I have to submit a feature request. If so, how can I do that?
Update 1:
I created a feature request on JetBrains Youtrack: http://youtrack.jetbrains.com/issue/WI-24262
Came across this question looking for something in Storm that would let me quickly convert "\Some\ClassName" to Some\ClassName::class like an Intention or plugin, but so far have found nothing.
i'm surprised the ::class static property hasn't been mentioned. It produces the FQN of the Class, and resolves from import aliases.
The following should be a legit rewrite that the IDE can resolve:
// Same __NAMESPACE__, so no prefix needed
Config(ObjectsToIdentifiers::class)
->oldTables = [
Modules\Old\Model\DeviceStock::class,
Modules\Old\Model\ProductPack::class,
Modules\Old\Model\SpareStock::class,
Modules\Old\Model\ConsumStock::class
];
// or, if you import the classes:
use Modules\Old\Model\DeviceStock as OldDeviceStock;
// you can refer to
OldDeviceStock::class;
Unfortunately, right now if you jump-to-definition of the alias, Storm won't take you to the actual class, but where the alias is defined. Not terribly helpful, but gets you halfway since the actual class is right there.
I am using watir-webdriver (0.5.3) in a Cucumber (1.1.9) test. I am attempting to verify the text value of an <acronym> tag. The code is legacy, and there are plans to change it to a <div> or <span> tag, but in the mean time I have to deal with it. I first attempted:
#browser.acronym(:id => /expense_code(.*)/).text
I received the following error:
NoMethodError: undefined method `acronym' for #<Watir::Browser:0x33e9940>
I poked around in the Watir code to see how tag objects were being created, and found that they seem to be dynamically created based on the HTML5 spec, but then I also found a comment in element.rb stating that they are no longer being created from the spec. At any rate, I couldn't see an easy way to inherit a <span> object and call it an <acronym> object. So, I looked into alternatives, and found the element object.
#browser.element(:id => /expense_code(.*)/).text
This code works, but it takes about a minute to traverse my page. I'm stuck with the regex for now, as the tag id is actually dynamically generated and I don't currently have a way to figure out those values. This is what the tag actually looks like:
<acronym class="editable select fillwith:exp_codes default:E100"
title="Expense Code: Expenses" id="expense_code114_582_10777">
E100 </acronym>
I would appreciate any thoughts on how I can improve the performance of my test.
Is that class name predictable? could you construct that from a set part plus the text you are about to validate (it's the same in your example above) and go that way?
acronym = 'E100'
browser.element(:class, 'editable select fillwith:exp_codes default:#{acronym}'.text.should == acronym
Does using XPath to limit the elements to just acronym tags help performance?
#browser.element(:xpath, "//acronym[contains(#id, 'expense_code')]")
UPDATE: As Chuck mentioned, CSS-Selector is also an option:
#browser.element(:css => "acronym[id^=expense_code]")
I was recently stealing logic from Watir 1.6.5 to make custom locators/collections for my page objects and I noticed in the Watir::TaggedElementLocator, it kind of supports any method that the element supports. Noticing in Watir-Webdriver that elements have a tag_name() method, I thought I would try the same and it looks like it works.
So you can use tag_name as a locator by doing:
#browser.element(:tag_name => 'acronym', :id => /expense_code(.*)/).text
I'm not sure what order the locators get run in, so since the regex is expensive, it might be faster to get all the acronym elements and then find the one with the right ID:
#browser.elements(:tag_name, 'acronym').find{ |acronym|
acronym.id =~ /expense_code(.*)/
}.text
While I think it makes the code look better, unfortunately I'm not sure if its any faster. I am guessing the performance of each will depend on the specific page layout being tested.
I'm not sure what the proper etiquette is here, but this is the answer I came up with using Chuck's reply and feedback from jarib in the #watir IRC chat. With all my examples, expense_code = 'E100'.
#browser.element(:tag_name => "acronym",
:class => "default:#{expense_code}").text
The above code works at a very reasonable speed and doesn't require an xpath. It is a shortening of the following code:
#browser.element(:tag_name => "acronym",
:class => "editable select fillwith:exp_codes default:#{expense_code}").text
I learned that I didn't need to pass the whole string. Anything in a class delimited by a space is dealt with gracefully by watir. I adapted that code from this xpath:
#browser.element(:xpath => "//acronym[contains(#class,
\'editable select fillwith:exp_codes default:#{expense_code}\')]").text
The gotcha in that code above was needing to escape out the ' around the class values so that it would evaluate correctly.
Just searching for the class (code below) did not work. I have no idea why. I did notice that it pounded the database with requests. Whatever it was doing, the page didn't like it. Though the reason it was trying multiple times is I slipped a wait_until_present in there.
#browser.element(:class, "editable select fillwith:exp_codes
default:#{expense_code}").text
Thanks for the help. :)
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