I am tired of manually finding locators (id,xpath,css,linkText etc..) for web elements from my web page source. It also consumes more efforts. So, to avoid that I want to write a code that interacts with page source directly and generates locators details (e.g. id="xyz" , xpath ="html/body/table/tr/td/a" etc.)
To achieve this ,I think I can generate ID locator by using split() function of String object. But, what I don't know is how to generate xpaths, css and linkText locators for all page components?
Although I'd generally recommend to construct XPath expressions on your own (as you can better exploit things to mach against like class attributes), probably the most reasonable and convenient automatic way to determine XPath expressions for selenium is to use either Firebug's or Chrome Developer Tool's "Find XPath" feature. They both at least use #id attributes to shorten XPath expressions.
If you want to write some code yourself, eg. for embedding in other tools you use, you might want to have a look at the answers of "PHP XML - Find out the path to a known value" which solves the problem in PHP, or another one with answers for Javascript: "Javascript get XPath of a node".
If you're using any tools not working on the DOM (Selenium/Firebug/Chrome Dev' Tools/JavaScript will do), watch out for the problems I described in "Why does my XPath query (scraping HTML tables) only work in Firebug, but not the application I'm developing?".
There are (at present) no "tools" that do even a marginally decent job of synthesizing reliable and concise xpath or css based locators. I've been writing selenium and HTML/CSS code for nearly the duration of the industry, and the so-called CASE-methods that purport to do this job better than humans produces laughably flawed output more often that it generates useful material. However, I would add a codicil: there is hope.
By taking careful stock of the various XPath and CSS methods (see http://www.w3schools.com/xpath/xpath_axes.asp for some general guidelines) and using only the most minimal locator strings that will pass muster in Firebug, Selenium IDE and other similar plug-ins, one can progress gradually towards a better approach. In general one should (where possible) use only one component from an object's attribute list and avoid using dynamically defined quantities. Best practices would encourage picking class, name or id only if they are "immutable".
Mutability is a tricky issue: simply dragging a cursor over an object or clicking on it may change the class or css characteristics. Sometimes this can be surmounted by using only the "fixed" portion of the offending attribute. For example, a class might initially be 'tabContent', but when the cursor is placed over the corresponding object it might change to 'tabContentMouseOver'. You get the idea. By using an xpath locator string //*[contains(#class,'tabContent')] you stand a better than even chance of hitting the desired object, irrespective of whether it is clicked, highlighted, or even disabled.
The next "trick" I'd encourage you to consider is using the "buddy" principle; many objects (button-like ones in particular) nowadays consist of an image with no dynamic properties wrapped by a div that manages its event-driven behavior. For such situations you might find that //div[#eventproxy='tabObject']/following::img[contains(#src,'tabImage') and text()='Contents'] or something similar will cover all the bases. Contents will vary with your situation of course.
Make vigorous use of the hierarchical axes methods ('following' is one I use quite often), but only where necessary; sometimes '//' will suffice instead.
Penalize yourself for every unnecessary character, and reward yourself for methods which are concise and can weather frequent and severe code changes. Above all, persevere.
In general I avoid using "pure" CSS locators for the following reason -- they were never intended as locators. "Cascading Style Sheets" by their very nature are designed to impact the maximum number of web objects possible, and are very rarely unique to any one piece of content. Web-coders are notorious for changing these on the fly to produce spiffy new effects or restructure content to suit customer demands; why hitch your tests to content that is known to fluctuate? Besides, everything CSS can do (and I do mean EVERYTHING) can also be done inside XPaths if you so choose.
The canard about XPaths being "slower" than CSS methods I believe has been disproved often enough that it should be taken with several tablespoons of salt. Still, if you really feel more comfortable with CSS techniques, go for it! Experience will educate you better than any blurb you find in stackoverflow ever will.
Related
I am doing UI automation in Selenium-Java where I am recognising object/element based on XPATH or CSS selector. Due to many unwanted reason - tests are getting failed due to change in XPATH at different environment.
I thought to write a utility script which will identify and auto-generate robust and simple XPaths.
Is there a way - I can make this happen at run time to self heal my existing Selenium-Java automation scripts.
It's not possible to recognize the elements that should get their xpath regenerated without specifying somehow what those elements are.
It's easy for humans to know which one is the "sign up" button, for example, even if its label, style or position changes, since people can use other context clues to guess which button is meant by "the sign up button". Implementing these context clues for a computer would require quite a lot of effort, especially for more obscure type of elements.
I would stick to spending some time and human thought to figure out the most robust locator for each element. (For a sign up button I'd say it's often the value of the href attribute.)
Maybe you could even specify multiple different locators per element. Then implement the search so that the locator that first matches a single element is used and fail only if all specified locators fail. That could decrease the frequency with which a person has to be fixing the tests. Or it could have the opposite effect :)
One more idea: if you can use version control to get the last version that some specific selector still worked, maybe you could try finding the most similar element in the new version and regenerating the xpath for that.
I'm rather unexperienced in GWT, and I have large codebase with working project in this technology. My task refers to assigning id's to html elements witch will be used in automatic testing. We can't use some dynamically assigned id's because in automatic test we have to specify exact values of id's. My way for now was to use method ensureDebug(id), written by hand in code for specific elements.
I think that doing it this way mean that code will be more spaghetti-like, with mixed ensureDebug(id) methods usages there and here. I was thinking if there is any way of doing it that will be more manageable and cleaner than current. Is is maybe possible to use AOP? (I have never used AOP, so I don't know if it is any good idea, or possible in GWT) Or maybe other way than using ensureDebug?
You also can set the IDs for HTML elements like
element.setId("myId");
But this is as much spaghetti like as your approach adding the IDs in the code.
Another possibility would be to use an UiBinder and set the id there. With this approach you have all your ui elements of one view, which should have an id, at one place. With bootstrap for example it would look like this:
<b:TextBox ui:field="searchTextBox" b:id="search-text-box"/>
Like this you can access the field in your view-class via searchTextBox and the id search-text-boxis added to the HTML element (which you could also use for styling etc.)
We have faced same issue for our project while adding test automation. As per my knowledge unfortunately GWT doesn't support anything like AOP yet. So we have to follow any of the spaghetti-like approach only from one mentioned above by #mxlse or the one you are already following.
Based on my experience I can recommend you to create separate constant/property at client or server end. Use this file to save all your id's which you can share latter on with test team as well.
I want to create a web site which can be viewed with two languages, one LTR and one RTL. This means that all content should be shown in either of the two languages.
My framework is Spring, and I'm using Tiles2, but I think this question is not framework specific.
The obvious solution to supporting two languages is having everything doubled (all JSP's, fragments, etc.), and you get the part of the tree which fits the language you chose. But this causes problems when changing the web site (you might forget to update the other JSP's), and is not scalable (try doing this for 5 or 10 languages).
I know I can use properties files to host strings for the different languages, but then my web site would be a huge collection of spring:message tags and will be a lot harder to maintain (what happens if I have a paragraph of 100 lines, does this all go into a single properties line?)
Is there any kind of framework, plugin, other, which solves this problem? Has anyone come across a clever solution to this problem?
I've never realized a complete project, just some tests. I think this problem is not so big as it seems if you follow some simple rules. Here is what I would try to do:
Specify direction with <body dir='ltr/rtl'>. This is preferred versus CSS direction attribute.
Avoid different left/right margins or paddings in all CSS. If you must break this rule, probably you'll need to use two different files (ltr.css and rtl.css) containing all these different elements.
Sometimes you'll need to move some elements from left to right or vice versa. For example, in LTR you want a menu on the left, but in RTL you want it on the right. You can achieve this using CSS, but this sometimes is complicated if you are not an expert and you must test it in all browsers. Another option is to use some IF depending on the case. This last option will fit very well if you use a grid based CSS library, like Bootstrap.
Choose carefully which CSS and JS libraries you'll use. Obviously, pick the ones which offer RTL/LTR support.
Don't worry too much about the images. If you must change one image depending on the language is probably because it has some text in it. So, you must use different images anyway. This is a problem related to i18n, not a text direction issue.
Don't let your customer to be too much fussy about it. I think that with these rules (and maybe some more) you can get a good result. But if your customer starts complaining about one pixel here and another one there, you'll need to complicate all this and probably is not necessary.
About your language properties file. Yes, use them. Always. This is a good practice even when you are only using one language: HTML structure is separated from content, is very easy to correct or translate, some words or sentences are in only one file...
Usually, web frameworks are used to build web applications rather than web sites, and there are quite few long static paragraphs. Most of the content is dynamic and comes from a database. But yes, the usual way of doing is to externalize everything to resource bundles, usually in the form of properties files.
Putting a long paragraph in a properties file doesn't cause much problem, because you can break long paragraphs into multiple lines by ending each line by a backslash:
home.welcomeParagraph=This is a long \
paragraph splitted into several lines \
thanks to backslashes.
RTL and LTR is one of the upper and more difficult i18n problems.
Basically its a Problem of the view-scope of the MVC-Model. This may also includes pictures and emotional differences like the color of the skin of people. In this case you better abadon to the solution HTML+CSS gives you.
In example:
<style type="text/css">
*:lang(ar) { direction:rtl }
*:lang(de) { direction:ltr }
</style>
The best practice is to ask members of the audience-group about what effect the webpages have to them.
I agree to most of solutions provided here. Your problem is more design (architecturally) oriented rather than technical. You need to choose path whether you need to keep this logic of internationalization on server (java) side or in static files.
In case you want to go for java side (preferable solution), you need to keep two properties file and use jstl tags. This minimizes your work in case you want to add another language in future. This is maintainable solution. I have seen applications supporting more than 15 languages and time zones. In fact release process gets pretty easy.
In case you want to go for keeping multiple css and other static files, you will soon find things running out of your hands pretty soon. I dont think this is a maintainable solution.
Said all this, I will leave this choice to the architect of application. He will be able to judge which way to go based upon the nature of application and constraints given to him.
You don't want to use everywhere. That's a pity because it is just the way you should do it. It is a bad practice to keep hard-coded texts in a jsp if you need internationalization.
Furthermore, Most of the modern IDE allows you to go to the variable declaration by doing ctrl+left click (or hovering the key) so that having a lot of variables in your code should not be a problem for maintenance.
First, you must distinguish, for each text element, whether it is a user interface element (e.g. button label) or redactionnal content.
user interface element labels will be stored in properties file that will have to be translated for each supported language (and provide a default value as a fall back)
redactionnal content will be stored in a content management system that you will organize in order to find easily a localized version of your content
I've done some php dev and the big trend in this language is using things like smarty or other template engine.
It usually roughly runs as follows :
load the template as a regular string,
look for its {tags}
replace each {tag} with the result of some code.
cache page with input parameters
render resulting page.
(sometimes add some OO principles such as template becomes an object...)
When I look at jsp, I see usage of scriplets, taglibs with complicated things like
<%# taglib uri="/tags/struts-logic" prefix="logic" %>
<%# page import="ghhghjjgj"%>
then :
<logic:if>some html </logic:if>
or worse :
<%= if (blabal) {%>
some html
<%}else ...%>
and so forth.
Okay, tiles enables me to glue together some jsp pages together which is really handy (like the include in php, sort of)
It seems to me that the php approach is much better in the way that :
It totally separates gui and model processing.
-It's easier to change the pages content when you are working on the behind part,
you're in a real java class with no complicated stuff like % # <%=. (who said
code behind ala C# ;) ?)
The C# approah is very interesting as well but I just want to adress the template part in my question and not start any C# Vs Java Troll war.
I do not also want to say php is better.
I just want to know why there is not a well installed templating engine in java and why we still use scriplets/taglibs.
So I guess I must be missing something.
Can some Java EE Web expert show me the flaws of my reasoning?
J2EE became Java EE a long time ago. Drop the "2".
No one should use scriptlets. It's 1999 technology. If you're seeing it in books, it's because the books are old. There's not a lot of good reasons for writing another servlet/JSP book now.
Custom tag libraries have fallen out of favor. JSTL is the standard. It's unlikely that you'll need more than that.
Templating is common - have a look at Velocity. One project I'm working on uses it exclusively for streaming HTML to the browser.
There are many template engines for Java, Velocity, for example. JSP compiles to Java bytecode. It allows for very fast execution. Whether this factor is important for you or not, depends on your task, for most web sites template processing won't be an issue.
I don't really understand the implications why it's great to write
{if blabal} some html{/if}
and not so good to write
<logic:if test="blabal"> some html</logic:if>
and it's worse to write
<% if (blabal) { %> some html <% } %>
but it's good to write
#if ( blabal )
some html
#end
I personally like to write my logic in java.
Type save
I know the syntax
However, to me it's not a matter of syntax wheter mixing template code and logic is a good or a bad thing. Thus I prefer Snippetory. I gets the logic out of the template while keeping the responsibility for consistence (ecaping stuff and the like), the look (formatting...) and internationalization in the template. The binding logic gets testable, easy to organize and reuse. The data model can be used as is and there's no need to translate it into a model sufficient for some kind of alien technology. In this case the template is rather a kind of a model where you copy the necessary data into rather than a process that self-services from a context.
Now, in this case we'll need to peaces of software to express the same thing, as it always happens as one uses the principles of separation of concerns to get software more maintainable.
Template:
<t:named-region> some html with a {v:value} </t:named-region>
Logic:
if (blabal) {
template.get("named-region").set("value", value).render();
}
Now as we look at this, it's quite a bit more code. Again this is typical to serparation of concerns. However, a quick look on the steps might make sense:
Access to the region is aquired.
Data is bound to the template. This happens fine grained, just like filling in a from.
The completed form is bound to the output.
The last step seems kind of dispenseable. I fill data to it, so it's clear I want to use it. But you have to be aware, render()is a short cut for render(template, "named-region"). So it's a discription how it is used. Thanks to this mechanism you can easily combine the building blocks of one file or even several files to an output of your choise. This leads to an surprisingly convenient re-use of those blocks.
And it gains me focus: When I'm fighting to get html, css and javaScript right I don't have to deal with 'how is the exact path to access the data?' or 'what are the exact case this button is displayed?'. It's just about 'there is logic, so it gets a name'. Very simple, very clean.
Of course there are some other engines this support for separation of template and logic like jByte (I used it for a while) or JTPL just to name a view. However, all of them seem to lack some functionality though, I decided to write Snippetory.
I'm working on a utility that will be used to test the project I'm currently working on. What the utility will do is allow user to provide various inputs and it will sends out requests and provide the response as output.
However, at this point the exact format (which input is required and what is optional) has yet to be fleshed out. In addition, coding in Swing is somewhat repetitive since the overall work is simple though this should be the safest route to go as I have more or less full control and every component can be tweaked as I want. I'm considering using a configuration file that's in XML to describe the GUI (at least one part of it) and then coding the event handling part (in addition to validation, etc). The GUI itself shouldn't be too complicated. For each type of request to make there's a tab for the request and within each tab are various inputs.
There seems to be quite a few questions about this already but I'm not asking for a 3rd party library to do this. I'm looking to do this myself, since I don't think it'll be too overly complicated (hopefully). My main consideration for using this is re-usability (later on, for other projects) and for simplifying the GUI work. My question is: are there other pros/cons that I'm overlooking? Is it worth the (unknown) time to do this?
I've built GUI in VB.NET and with Flex3 before.
XML is so 2000. It's code, put it in real source files. If it really is so simple that it could be XML, all you are doing is removing the XML handling step and using a clearer syntax. If it turns out to be a little more complicated than you first expected, then you have the full power of your favourite programming language to hand.
In my experience, if your layout really is simple, something like the non-visual builders in FormLayout can lead to really concise code with a minimum of repetition.
If you have to specify the precise location of every control you might look at a declarative swing helper toolkit that can minimize boilerplate and simplify layout. Groovy supports this as does JavaFX, and both are simple library extensions to Java (give or take).
If the form is laid out in a pattern, using a definition file in a format like XML or YAML will work. I've done that and have even set up data bindings in that file so that you don't even have to deal with listeners or initial values...
If you are sure you want XML, I'd seriously consider YAML though, it's really close but instead of:
<outer>
<inner a=1> abc </inner>
</outer>
I think it's a lot more like:
outer
inner a=1
abc
(I may have that a bit wrong, but that's close I think. Anyway, you should never force anyone to type XML--if you are set on XML, provide a GUI with which to edit it!)