Is using Assert in Selenium a good thing?
Someone once suggested that using asserts slows down the test and I shouldn't use them.
Assert is to verify test output. More you limit asserts better it can get overload during test cases Read this
Asserts are same overload for testing as comparisons in programming terms. Example is to use asserts to test values validations or filled in Form input that gets populated from grid to Edit/Update fields Just a simple example i can think of.
I don't think that this would be the bottleneck of your tests. Waiting for the browser to render the web page, executing JavaScript and parsing and accessing the page via Selenium will outweigh the time needed for assertions by far.
I am using Asserts for my automated testcases in Serenity, Selenium and JBehave and in my opinion it doesn't matter if you use Asserts, Exceptions or something else...
As Sebastian posted already, the time for opening, rendering pages and accessing the objects will outweigh the time needed for assertion way more. The only thing you can optimize is the loading speed of your page and how you access the web elements.
If you search for an XPath expression you should see that you can optimize your XPath expression for faster searching (e.g., not using //* to look into every node) or even better you use CSS or id selectors.
Related
One of the major reasons for ui automation failure is locator changes which need to be constantly updated. What is best way to maintain locators so I don't have to update test automation code every time locators change.
Create a common locator.json file for each ui which provides the locators needed to perform actions on the ui and is part of the ui asset which can be loaded by directly accessing the file using the domain and path
Write unit/e2e test in the ui application to use the above locators so its always valid before changes get deployed
When locators change only these tests need update and your actual e2e validations tests don't need update.
By using this approach, teams don't need to worry about the locator changes and can rely on this file for providing updated locators in every environment.
It can be used in any automation script where locators are needed.
Cross application ui automation execution becomes more reliable and avoids false negative.
Example locator json file:
http://www.myappquality.com/asset/locators.json
Best practice is to use the page object model. The core of this idea is that each page on your site is represented by a class in your test project. All locators for that page should reside in that class. All actions that a user might take on that page would be represented by a method in that class. So, when that page is updated on the site, you know exactly where to go to make changes... the corresponding class.
If each of your tests contain the locators, a page redesign involves searching for every test that touches that page and updating the locators. If you use page object model and the page is redesigned, you open up the class for that page, update the locators and you're done. What might be hours of work for method #1 would be a few minutes when using the page object model... and you won't mistakenly miss updating a test.
Some references
Page object models from selenium.dev
Using Page Objects to Organize Tests from protractortest.org
I also wonder if perhaps you are creating suboptimal locators and that is causing you to have to update locators more often than you should. If minor changes to the page are forcing you to update locators for elements that weren't directly affected by the updates, you probably are using XPaths copied from a tool rather than handcrafted ones. This can cause a LOT of unnecessary locator updates. If this is the case, I would suggest a lot of reading. Read lots of articles on how to create good locators. Avoid XPath locators in most cases. Look for elements with IDs, names, and the like and use those. Learn how to write CSS selectors... there's lots of good articles on the web covering that topic. XPaths are generally avoided by the Selenium contributors. They are slower, the syntax is much more complicated and verbose, and the support is not as good as CSS selectors. In general, XPaths should only be used when necessary... when you have to locate an element by contained text or perform some complicated DOM traversals.
If you can master those two things, your automation will be much cleaner, easier to read, and a LOT easier to maintain... and will need less maintenance.
Read this What is the Page Object Pattern in Selenium WebDriver?
Page Objects and PageFactory on Selenuim Wiki.
Page Object Design Pattern on Selenium official site.
There are other approaches, but these one are the most common for a long time.
everyone mentioned page object model, but if locators get changed frequently, that won't solve the problem. You'll still have to fo to each object and updage locators
I would be looking for a solution on application side. For example ask developers add unique attributes that are not a part of css, but can be used by automation. You can call them whatever you want, for example test-id and then you can even declare your own locator strategy in protractor and make your life simpler
If you need more info lookup protractor data hooks
I have multiple test cases and I have multiple class files one for login, one for user creation and etc. Would it be possible to do like this - I wish to initialise the WebDriver once say in login test case and then wish to execute other test cases by maintaing the session and without re-initialising the WebDriver in further test cases. Is is possible?
This is not good practice.
Try to avoid this at all cost. Every test should be modular and independent as possible.
Good thing is that You divided them logicaly, but don't go to re-use driver and session, this is just bad practice, and doesn't bring You nothing.
Good Practice:
Use PageObjects Pattern
keep your code robust and portable (Preferred selector order: id > name > css> xpath)
Avoid Thread.sleep prefer Wait
keep test as small as possible and Your code modular and re-usable
#murali provided example in his link, but as I mentioned this is not good practice.
Hope that this helps,
If we create automation script and again and again path of locator changes then what steps we should follow for again maintain the test script.
This is definitely a bit of a broad question, though it is something that causes all testers issues.
There isn't really a foolproof way to avoid these issues, because html does change as products are developed. You can try and increase your chances of avoiding the issue by using id to locate elements wherever possible, as this is guaranteed to be unique, and isn't susceptible to failing due to layout changes, as XPath is.
If there's no id available then you should move on to more "fragile" locator methods.
See this blog post for reference:
https://blog.mozilla.org/webqa/2013/09/26/writing-reliable-locators-for-selenium-and-webdriver-tests/
I am attempting to optimize my current automation framework for faster execution. My current framework is designed by keeping separate xml files for locator strings, page objects for each page of my web app which fetch their locator info from these xml files.
But after googling a bit, some automation developers say that keeping those strings inside the page object classes would be more efficient. I need more in-depth details regarding this.
Thanks.
IMHO you're not looking it from the most appropriate angle. If your current automation process needs considering Data driven approach Vs Page objects when it comes to
optimize my current automation framework for faster execution.
you're not doing it right. In my experience I've had both implemented and running pretty much independently. First one for functional tests (that don't care so much what the rest of the page is displaying) and for the rendering tests (don't really care about the functionality, if the page layout is as expected). This is the reason why I also ran the UI tests with both headless ghostDriver and Chrome- Firefox-, IE- Driver.
Let's assume that your data-driven test logic uses something like CSharp's Class
Dictionary<TKey, TValue>
You only need to load it once and then the search is flat, an O(1) constant time complexity. Bottom line - such performance shouldn't be an issue unless you have unreasonable large amount of UI tests. Which violates the Test pyramid:
If we're going to talk about automation framework optimization for faster execution - parallel execution of your xUnit runner is a good fit.
Disclaimer: I'm assuming you are talking UI automation because of the tags you put for this question (selenium and ui-automation).
Can anybody suggest a good tool to test GWT UI. What is the opinion about using Selenium & Webdriver ?
Any pointers and suggestions are welcome.
Thanks,
SD
Google themselves have an excellent article describing when and how to apply different testing strategies to GWT apps. The basic idea is to use unit-testing whenever you are testing business logic, but to use Selenium for specific end-to-end tests where you want to simulate user interaction.
The most important thing is limit how much GWT-specific testing you need to do since GWTTestCase and Selenium are so slow. The MVP pattern referenced in the Testing Methodologies helps enormously with this. Always ask yourself "Can I make this view any dumber?" Push logic for dynamically changing the UI into presenters that manipulate views so that you can test the logic in JUnit.
Then I'd suggest doing most of the UI testing in Selenium/Webdriver. Those tests should be fairly simple though: "Does X show up when I click Y?" kinds of things. GWTTestCase ends up being the most useful for me for code that needs to run under Java and GWT.
Or, as an alternative to the MVP pattern, you may use the gwt-test-utils framework to write simple tests in java, which runs faster then GWTTestCase tests :-)
You can do bog standard unit testing for your GWT components, if you want to do some layout checking things which can't be done through unit tests (can't give you examples since I don't know GWT nearly at all) then you may use Selenium, however Selenium does have some issues in specific cases, namely selecting elements and very rich content which may prove to be hard to handle since GWT is all about rich content.