Environment: Selenium testing in Java against Chrome
Scenario: in the GUI of my application I have a button that causes a form full of data to be submitted to an external service, whereupon the user is re-directed to the external service landing page.
Because my application is inside my corporate firewall, a username/password has to be supplied for consumption by the external service, but the application is not aware of this, so doesn't provide it (it would work normally in production, but the test environment is a special case). Therefore, a pop-up appears, and during manual testing the tester supplies a username and password manually and then submits the dialog. This is not a JavaScript dialog - I assume it's an actual modal Windows dialog, so it effectively halts processing and selenium just waits around till it's gone.
Problem: I am trying to automate this process, and cannot get passed the dialog. Because the dialog prevents java/selenium from processing, I cannot implement code to handle the dialog, such as integrating AutoIt or using Robot , because program flow never gets to that code after the button is pressed. Usually, I'd install an independent version of AutoIt to run on my machine in the background and catch the pop-up (not ideal, but it works), but due to very tight restrictions in the corporate domain policy this isn't possible in the short-term. I suspect they have a white-list for executables, so it may be tricky getting any third-party tool to work.
Can anybody think of a way around this?
Can't use Alerts, as these are not JavaScript dialogs
I have to be able to enter the username, password and submit the dialog
Can't use integrated capabilities like AutoIt or Robot
Can't use an independent tool like AutoIt due to domain policy
I suspect it's not possible, but worth checking if any bright spark has any ideas.
It's not supported in WebDriver so it can't be done using plain Selenium.
There is an issue open in the WebDriver project to support handling basic auth prompts:
https://github.com/w3c/webdriver/issues/385
https://github.com/SeleniumHQ/selenium/issues/453
Alas, the issue is open and nothing is implemented yet.
If you can't use AutoIt from another process because that process has to be in a certain whitelist, then you can probably use it from another thread using autoitx4java. If you can detect the dialog itself then you should certainly do it, but AFAIK the dialogs of Chrome are transparent to AutoIt (any other technologies based on Windows UIAutomation). In this case, just spawn the thread before pressing the button, make this thread sleep for 1 second or so (in the first statement of the thread method), and then "blindly" type the user name, Tab key, the password, and Enter. It's not very element, but I believe it should work.
Related
I have following situation. once I start a Selenium test, a browser window will be opened. Since I have a bunch of tests and I start them many times every day, I would not let Selenium to open the new browser window on the front of my current browser(where I am working), but on the background, so it wouldn't disturb me. Is it possible?
PS to clarify why I need this - many times in a day, when I working in the current browser and the selenium tests are running, browser windows from Selenium for every test opens just suddenly and I can suddenly close it, type something, etc.
What I have now:
To start with Software Test Automation is an art. Your test bed should be:
Configured with all the required softwares, libraries and binaries.
Test Execution must be performed in a controlled environment for optimized performance.
While your #Tests are executing, it should be free from Manual Intervention.
Particularly when your #Tests are Selenium based, while test execution is In Progress the Test Environment shouldn't be intervened because:
At the lowest level, the behavior of actions class is intended to mimic the remote end's behavior with an actual input device as closely as possible, and the implementation strategy may involve e.g. injecting synthesized events into a browser event loop. Therefore the steps to dispatch an action will inevitably end up in implementation-specific territory. However there are certain content observable effects that must be consistent across implementations. To accommodate this, the specification requires that remote ends perform implementation-specific action dispatch steps, along with a list of events and their properties. This list is not comprehensive; in particular the default action of the input source may cause additional events to be generated depending on the implementation and the state of the browser (e.g. input events relating to key actions when the focus is on an editable element, scroll events, etc.).
Additionally,
An activation trigger generated by the WebDriver API user needs to be indistinguishable from those generated by a real user interacting with the browser. In particular, the dispatched events will have the isTrusted attribute set to true. The most robust way to dispatch these events is by creating them in the browser implementation itself. Sending OS-specific input messages to the browser's window has the disadvantage that the browser being automated may not be properly isolated from a user accidentally modifying input source state. Use of an OS-level accessibility API has the disadvantage that the browser's window must be focused, and as a result, multiple WebDriver instances cannot run in parallel.
An advantage of an OS-level accessibility API is that it guarantees that inputs correctly mirror user input, and allows interaction with the host OS if necessary. This might, however, have performance penalties from a machine utilisation perspective.
Additionally,
Robot Class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations. Using the class to generate input events differs from posting events to the AWT event queue or AWT components in that the events are generated in the platform's native input queue. For example, Robot.mouseMove will actually move the mouse cursor instead of just generating mouse move events.
Finally, as per Internet Explorer and Native Events:
As the InternetExplorerDriver is Windows-only, it attempts to use so-called "native", or OS-level events to perform mouse and keyboard operations in the browser. This is in contrast to using simulated JavaScript events for the same operations. The advantage of using native events is that it does not rely on the JavaScript sandbox, and it ensures proper JavaScript event propagation within the browser. However, there are currently some issues with mouse events when the IE browser window does not have focus, and when attempting to hover over elements.
Browser Focus:
The challenge is that IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus. Specifically, the element being clicked on will receive a focus window around it, but the click will not be processed by the element. Arguably, we shouldn't be sending messages at all; rather, we should be using the SendInput() API, but that API explicitly requires the window to have the focus. We have two conflicting goals with the WebDriver project.
First, we strive to emulate the user as closely as possible. This means using native events rather than simulating the events using JavaScript.
Second, we want to not require focus of the browser window being automated. This means that just forcing the browser window to the foreground is sub-optimal.
Conclusion
Always keep the Test Environment seperate from Development Environment and absolutely free from Manual Intervention.
Whether the browser appears over your current browser, or in the background, depends on the driver implementation and changes from browser to browser - it is not dependent on Selenium or Serenity. However I usually run the tests in chrome in headless mode, which removes the issue entirely.
I'm using Selenium WebDriver (in Java) to get some info from a site after logging in. This requires the user to complete a reCAPTCHA test. Everything before and after this is done automatically and the user does not need to see or do anything.
I would normally use a headless browser, but I need the GUI so that the user can manually complete the reCAPTCHA. Currently I am using ChromeDriver and WebDriverWait to wait until it is complete and then continue with my stuff. I am fine with this-- the user completes the test while everything else is automated. However, if the user does anything besides the test (new tabs, entering stuff in address bar), things get messed up. How can I prevent this?
Unfortunately, Captcha is intended to defeat automated programs like Selenium, and getting around CAPTCHAs is difficult by design. It does after all stand for "Completely Automated Public Turing test to tell Computers and Humans Apart". Typically, one has to configure the website in certain ways in order to disable the CAPTCHA for testing purposes. Though this will help automate the test in a smoother way, it compromises the security of the application. If your dev team allows this, then ask them to disable it for the purpose of running automated tests.
You will have to enter the CAPTCHA yourself while other fields will be filled automatically. This method only achieves automation to a certain point. Basically, the only way is using the WAIT command to tell the script to wait and complete the CAPTCHA manually.
I'm wondering if anyone has any experience using JNA to call windows sendMessage API from a java web application running in a browser to change the focus from the browser to another program that is already running on the computer.
I'm building out a Parts catalog that once the user has chosen the parts they want to sell to the customer, I need to automatically open the Point of Sale system so that the employee can tender the transaction. They want this to happen on some event in the parts catalog, not just an ALT-Tab or something similar. I believe the registers run some sort of kiosk version of XP and the browser (Probably going to be Firefox 5), so some of the functionality, like the task bar and start menu, etc. are not there. Maybe JNA and the windows API is the wrong way completely. Any help or direction would be greatly appreciated!
A straightforward method would be to enumerate the extant windows until you find the one you're looking for, and then invoke the appropriate win32 method to activate/focus that window directly.
I want to read the web address of all open windows. As soon as the window closes, I should know it too.
One way to do this is by asking the user to download a firefox plugin. This plugin should monitor the user web address.
But is this possible? How to go about executing it. I am pretty decent in Java and PHP.
EDIT:
What if the user wants to give permission to access all the websites he or she visits?
I want to display in a visual manner the statistics of the sites being visited by users who grant permission.
As noted, this cannot be done with standard JavaScript/DOM methods that run inside a page, for security and privacy reasons.
You could definitely do it with a Firefox add on, plugin or extension.
I suggest reading the Firefox addons developer guide and the Developer Hub in general. The language used to develop for Firefox is JavaScript.
nsIWindowMediator can be used to enumerate open windows, and properties can be obtained through the nsIDOMWindow objects. As explained here,
"While you can use JavaScript to get child windows opened from the parent window, you cannot get dialogs or windows that have no relation to that window. To overcome this limitation, nsIWindowMediator makes it possible to access all of Firefox's windows."
this likely violates the same origin policy, which rules this out
it basically controls the code so that it does not read anything it did not create
so no spying can be done
No, this would be a major security and privacy issue.
This is definitely a security violation similar to sniffing; and would require certain privileges to run on each platform (such as an activeX or plugin or a privileged applet).
However, this can be done using javascript only the page containing the script it self is responsible for opening windows (meaning not all windows such as window opened by user) - if that is what you are looking for, let me know.
I created a java program that will pop up a dialog, and scheduled it as a task. Everything works fine except when the scheduled java program runs and the dialog pops up, there is another window (svchost.exe) hanging behind the dialog box and doesn't go anywhere until the java program finishes its execution. The program is running in Windows XP.
How can I avoid that dos prompt?
Thanks
One word of warning (posting as an answer so I can get fancy links and for length): Services which pop up UI are basically security holes waiting to be exploited (search for "shatter attack" for more information). That's why in Windows Vista and beyond services cannot display UI on the desktop (services run in session 0, the interactive user runs in session 1).
More importantly, there are several scenarios in Windows XP where your application will fail to work: If there are multiple users on the computer logged on at once (fast user switching) or if the machine is a server 2003 machine running with the terminal server role your UI won't pop up in the interactive user's session.
This article talks about the session 0 isolation issue and how to work around it.
If you want your Java program to have no console window, you need to launch Java using javaw, not java.
Create a shortcut for the thing you want to schedule. In the shortcut's properties dialog, Select Run Minimized in the shortcut tab. When scheduling this shortcut, make sure you refer to the shortcut, it ends in .lnk Browsing for it may bypass the shortcut for what the shortcut points to. Source: http://ask.metafilter.com/18994/Windows-Batch-File-Run-Minimized