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.
Related
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.
I was wondering what the differences are between calling the click() method of the WebElement versus finding the element by id and firing the click event with JavaScript.
Just to be clear in the first method I call the .click() of an instance of WebElement:
myWebElement.click();
The second technique is:
((JavascriptExecutor)driver).executeScript("document.getElementById('myElementID').click()");
I'm interested in knowing all the differences between these two techniques for clicking web elements, and also advantages and disadvantages of each.
Webdriver utilizes a browser's native support for mapping the DOM element to WebElement object using id/xpath etc.
The JavascriptExecutor.executeScript executes an external script in the context of the currently selected browser window. (similar to an augmented browsing tool like grease monkey, if you ever used),
and in case the script returns any DOM element its converted into WebElement object.
One can also say, the click simulated by WebDriver on a browser is similar to what actual user do as compared to one invoked using javascript.
In reality, with WebDriver not all the events can be automated flawlessly with all the web browsers, in fact with different versions of the same Web browser also. (i.e. different version of IE, FF etc behave differently). Still WebDriver is the near best tool available for this.
Once (~4 years back) on a certain version of IE we observed that we can't send right click or may be hover mouse on generated menu links, so we used js to simulate that, which performed very much browser independent way. so you can now conclude what executing external javascript can be good for.
Also, there are automated web testing frameworks which use javascript for everything instead of browser's native support. e.g. :http://en.wikipedia.org/wiki/Sahi_%28software%29
Ref:
http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/JavascriptExecutor.html#executeScript%28java.lang.String,%20java.lang.Object...%29
http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/WebDriver.html#findElement%28org.openqa.selenium.By%29
Those kind of tests are E2E (end to end) not BDD.
First one – is executed now, to take next action you must write some function that will delay execution for e.g download new data from server.
The second code return promise – http://selenium.googlecode.com/git/docs/api/javascript/class_webdriver_WebElement.html – „Schedules a command to click on this element.” – you can use then callback to run next action.
I have this example to listening events from fileSystem (http://java.dzone.com/news/how-watch-file-system-changes) but the events are only create, delete or modify.
I want to listen a simple double click event from my fileSystem.
Does anyone know how to do it? I can't do it by swing.
Thanks!
Java, out of the box, is not capable of watching for "a simple double click event from my fileSystem".
The link you mention is about java code that can watch for other types of events, such as create, delete and modify within the file system, but double clicks are "user interface" events, which are not covered by java code as such.
However, you have rightly mentioned Swing.
If you wrote a programme, using Swing, that was specifically designed to make changes to the file system, then yes, your programme could be written to listen for clicks on a button on a swing layout, and your code could then decide what to do with that click event.
There is no such thing as a "double click event" in terms of the subject you're talking about.
The WatchService in Java is an interface with the implementation being platform specific (including being completely optional, depending on the platform).
The way the default implementation works on some platforms (specifically, windows / *nix) is by periodically polling the filesystem metadata for the directory you specified. If the default implementation is not monitoring access time (atime) or it's not available on the platform (or is turned off), then ... no, you can't get events for file access.
Testing this on OSX, it does not. I would have to test it on Windows and *nix to see what the results were there. I don't know that any of the default implementations do as atime isn't really reliable as it can be turned off on many file systems that support it to improve performance.
If you wanted to use the WatchService interface for this and the platform(s) your code would run on support it, you could implement your own that looked at access time and fired an event.
This StackOverflow Question demonstrates how to check atime on a file, but again remember it's not really reliable (read the comments on the caveats).
I have a ten-year-old applet that wraps itself around the Crystal Reports Viewer applet in order to handle some custom features. It has worked satisfactorily, displaying and printing reports as designed. The web-app provides data selection, and then generates the HTML to invoke the applet with the correct parameters via an AJAX call.
I have one user (so far) who experiences the following problem: after generating the applet and viewing the reports, she prints the reports. Once the print dialog has appeared, even if it is cancelled, the following things no longer work:
the Close link which is supposed to clear out the generated applet HTML no longer works;
the navigation links to other pages no longer work: they dim appropriately when the mouse hovers over them, but the browser does not respond to clicking on them;
the window cannot be closed, whether
by clicking the X in the upper-right-hand corner,
by clicking on the system menu and selecting Close,
by right-clicking on the entry in the task bar and selecting Close, or
by trying to invoke the File/Exit menu item (I believe the File menu is disabled);
clicking on the window title-bar no longer makes it appear active.
In order to close the window, one has to start the Task Manager and end the iexplore process.
It may be that this is another occasion where the applet is retaining focus and it should not: similar bugs such as
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4838000
are reported as being folded into a bug I can no longer find in the Java bug base:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4918282
There are also reports of invisible applets retaining focus: it might be that the custom applet is invoking the original Crystal Reports applet in some way, but I didn't myself develop this code, just the wrapper that drives it.
I do not believe I have a case where a dialog of some sort is appearing behind the IE window; I should think that would occur on more than one system, and this appears to be unique to this user, but the system looks like one of our stock images.
There are also reports of printing locking up an IE window until printing is complete, where the solution is to put the printing into another thread. In my case, it is unnecessary to actually print: invoking the Print dialog and then cancelling it is enough to cause the buggy behavior.
I would like to understand what's going on here, and get things running for this user if possible. I'd appreciate any reports of similar experiences, or directions to look that I've so far missed.
Some version notes:
Win XP Pro: 5.1.2700 SP 2 Build 2600
IE: 7.0.5730.13
Java JRE: 1.6.0_31-b05
Printer: Imagistics 2500 USB printer (on the off chance)
I've been trying to understand how flash animations or a Java Applet work within a browser.
I can think of a couple of ways -
The Flash Player/Java Applet are machine code that's dynamically linked it, and given
some parameters about the area of the screen that belongs to them; after that, they
run within the same process space.
The browser exposes an API that the player/applet use to talk to it and they live
in a separate process. (Presumably they talk via sockets?) The API could correspond to
openGL/X11/some custom calls.
These possibilities still don't explain things like how a button click can make the
player full-screen, how it can play music, how it can inspect the DOM, etc. For that matter,
is the video displayed by decoding to a sequence of images, and rendering them
one at a time, or is there a more efficient way, e.g., of pushing the deltas in the image?
The Wikipedia page on Java Applets (1)
talks about how the applet is run in a sandbox (presumably a separate process), but
it doesn't say how the browser and the applet communicate.
Perhaps the answer depends on the underlying platform?
Any pointers to systematic discussion of this topic would be appreciated (as would
a reference to the APIs).
(My interest in this stems from an insatiable curiosity.)
I'm pretty sure plugins like Java applets and Flash run via NPAPI in most browsers. I looked into this matter myself some time ago and NPAPI was the answer I found.
In the case of browser and Java applets, the applets are typically run within the Java plugin, which runs as a separate process (you can see it e.g. in the task administrator in Windows).
The plugin creates an object for each applet in the DOM, and you can thus interact with the applet from Javascript. Anyway, calls to the applet that take a while to return do have the effect to freeze the browser, therefore I'd say the communication with the plugin runs in the same thread as the main refresh loop. This seems at least to be the case with Firefox.