I have my regression suite setup in jenkins and it executes on windows server 2012 r2. Recently I changed screen resolution to 1920,1080 by using below code
driver.manage().window().setSize(new Dimension(1920,1080));
All the other test scripts get passed except two ( let's say script1 and script2 ) in headless mode on the server. But those two scrips get passed in my local machine in both headless and browser mode.
And also when I execute those two scripts in browser mode on the server with the same screen resolution, again they get passed.
When I change the screen resolution to
driver.manage().window().setSize(new Dimension(1366,768)); It get passed on the server in headless mode.
Since I'm using the same configurations for the rest of the scripts. I couldn't think of an exact thing happening here. When I build the Jenkins job, it executes all the other scripts and when it comes to script1 execution hangs. Jenkins build also hangs and doesn't come to the end. Looking for a solution for this.
I'm using webdrivermanager and chrome version of the server is 96
By default, VM screen size is very small (--window-size=1040,784), so while automating things, decrease your screen size to this value and automate, otherwise, we will face this issue.
To increase VM screen size, you need to increase virtual memory of your R2 server. that will end up with high cost.
solution:
Automate with smaller screen size.
or Run it in headless mode
I did troubleshoot and here are my findings,
It was a loop which was never ending if element not found
inside the loop, it searches for an element which was appeared only in a small screen resolutions (arrow button to navigate through some tabs. when the screen resolution is higher, all the tabs appear in the page and no arrow button visible)
So that's the reason those scripts work in small screen resolution and failed in higher resolutions
I changed the loop accordingly and now I can execute all the scripts with higher resolution on the server with headless mode
Related
A constantly active window. I neeed an emulation of that a real person is looking at the screen.
I have to write automated tests for windows application, so I choose a Winium(https://github.com/2gis/Winium).
But I have a 1 problem. All this tests running on virtual machine and i also start them from jenkins, but they will work only if I connect by RDP to virtual machine and maximize window.
If I just connect by RDP, but minimize window, all tests gonna fail.
So can you help me, and say, are exists some kind of programs which emulate "human presence"? Also glade to hear about you expreience in Automated GUI and what of programm you're using.
As a successful workaround, I've written a Visual Basic script that simulates continuous key presses on NumLock. This keeps my Remote Desktop session alive, even with the window minimized. My Winium scripts run fine within a grid (Hub-Node) setup (both hub and node are VMs) and the simulated keypresses don't interfere with testing.
Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.
The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
I am using Selenium script (in Java) with Jenkins using Chrome browser.
But Jenkins opens Chrome browser with dimension 1040x784, although I tried to increase dimension as desktop browser but failed, it still opens browser with dimensions 1040x784.
I am using this code to increase dimension:
Dimension dim=new Dimension(1340, 744);
driver.manage().window().setSize(dim);
So in order to open chrome browser with desktop dimension, do I need to add any plugin? Due to this I am not able to automate most of the features with Jenkins.
* I am using Jenkins as my Windows services.
I use the same code as you with jenkins without problem: windows is set to its new size as expected.
I think the issue might be that Chrome does not allow to set the size larger than the dimension of the system's screen.
If you know for sure that your system's screen allows you to reach [1340, 744], then it might be because your chrome driver is not an up to date version.
If it still does not work, below are some tests you might try, to fix the issue:
Try to run it with firefox webdriver, and see if you have the same issue. this will discard an issue related to chrome webdriver.
Try to set new dimension, but smaller than the 1040, 784, and see if chrome lets you do that. It will discard an issue related to the way you have written your code.
does it work fine when you execute it on local ?
When performing my test I captured the image of the File Name input field from File Upload windows pop up. The image resolution on my local machine is a bit different from the image resolution on the Windows Server 2012 VM machine so test keeps on failing as it tries to match the File Name input field image that I have in the Selenium WebDriver project and the image that is displayed in the VM. How to handle the resolution issue.
Local Machine image
Windows Server 2012 VM Machine image
There is not much you can do about it. Your only solution is to create your patterns based on the resolution of the target machine or alternatively change the resolution of the target machine to match the one you are using for pattern creation.
The other thing I find peculiar is how did you configure SikuliX to run on a VM? There is a known limitation that it cannot run in headless mode. Unless you have configured some kind of VNC. Just make sure that the error you're getting is caused by the reason you mentioned and not due to this limitation.
We have a CI environment with Jenkins running a test suite of Selenium Tests in a Windows (XP and/or Windows 7) VM. If I am not physically logged into the VM running these tests via RDP, all I see are black (blank) PNGs. I've tried all of the 'capture' methods available (both Base 64 encoded and file based) for multiple Selenium RC 2ish releases (e.g 2.0b2, 2.0rc3, 2.0.0, 2.1.0) and I get the same results for everything I've tried. Is anyone else running Selenium in a Windows CI deployment and able to capture screens? Or better stated, can anyone shed light on how I can capture screens in Windows, using the Selenium API without having to be physically on the box"?
If you are not logged onto the box, or you either closed or minimized the RDP connection, there is no desktop, and screen captures will be blank.
What you need to do is use a VNC server/viewer, so that the machine/vm in question has a visible desktop session.
We are also doing something very similar. We have a windows VM setup which is running Hudson and Selenium Grid.
When our test cases fail we capture a screenshot of the browser so we get more detail of why a test case failed.
We are using the #captureEntirePageScreenshotToString method
We're doing it, and it works for us. We're using JetBrains' TeamCity instead of Jenkins, running on Windows Server 2003. We run the Selenium RC server as a Windows service, using the Java Service Launcher.