1 2 Previous Next 17 Replies Latest reply on Dec 4, 2008 6:35 PM by 10129 Go to original post
      • 15. Re: Selenium to test ADF UI Application
        anyone got this to work? we'd really like to use selenium as a testing tool, but it makes it inconvenient that we can't use the pop-ups.

        • 16. Re: Selenium to test ADF UI Application
          I would like to second that as well. Our application uses ADF dialog box component extensively and if it doesn't work with Selenium, we won't be able to automate functional tests.
          • 17. Re: Selenium to test ADF UI Application
            Hi all,

            sorry for not answering earlier, but I was made aware of this thread just today.

            We in the JDeveloper QA team successfully use Selenium for testing ADF applications with popups. We do not have to take any special actions to make it happen. So who-ever is planning to test their ADF application with Selenium can be assured that popups are no road blockers.

            As to why the Selenium test in question is failing, I do not know, but based on my experience it's my guess that the locator is not working. I found in the past that the locators shown in the Selenium IDE can be quite misleading at times.

            There are several ways to acquire the correct locator:
            1) Install FireBug Addon for Firefox and use its "Inspect Element" feature
            2) Install Web Developer Addon for Firefox and use "View Source" -> "View Generated Source"
            3) Use the Selenium method getHtmlSource() and print it to a file for further analysis

            Although option 1 is by far the simplest of the 3 ways to view the particular element's attributes (including its id's), it's not easy to figure out a complete XPath which is often the better locator strategy to identify a certain element.

            Option 2 gives you easy access to the "real" page source (the Firefox menu "View" -> "Page Source" is not capable to show it all; don't ask me why), however this output is absolutely unformatted. But there is a nice way to reformat that HTML code: paste it into a .html file, open it in JDeveloper and use JDeveloper's Reformat feature. Now you can take a close look at the HTML code and find a good XPath or id.

            The disadvantage of options 1 and 2 is that they rely on manual interaction: you run the application, perform a few actions and at some point you use one of the options. However timing can be important here. Maybe the link in question is not available at that point in time when Selenium should click on that element? Here option 3 offers a way of taking a snapshot of the code and analyzing it later as described for option 2.

            What can I recommend?
            a) use meaningful, human readable id's because this makes it clear what the DOM tree path is (the original question shows: "mainView:regionHouston:j_id___jsp_tag_ctru3i3:0_3:populateGridLink"; what tag or element is "j_id___jsp_tag_ctru3i3"?); another advantage: generated id's can change, id's entered by a developer usually don't
            b) don't use testId's because they will be deprecated in the next release
            c) consider using XPath locators over id locators

            Hope this helps!

            1 2 Previous Next