Is it possible to write tests for a JavaFX application, which do not fail upon mouse mouvement generated by the human user ?
I am a beginner in JavaFX and TestFX, and it seemed to me that TestFX stops everything as soon as it detects that the mouse has been moved.
In another project, which uses Eclipse RCP and SWTBot, this seemed to work out-of-the-box, as long as the application under test had the focus. Is there any way to get the same behaviour with TestFX, or any other test framework for JavaFX ?
As a workaround, on Linux, it's generally advised and useful to create another X session (using Xephyr for example) and to run tests in this X session by setting the right DISPLAY property.
With that, the event processing is isolated on both DISPLAYs so tests are not "polluted" by parallel human actions on the other DISPLAY and can run with less troubles.
Related
I have an application that uses this application type that I need to automate. Unfortunately, the application window is invisible to my automation tools. Are there any suggested ways of working around this problem? I'm using pywinuto for automation. I can't even inspect the window data for this application.
EDIT:
from pywinauto import Application
from pywinauto import taskbar
app = Application().start("path/to/my/app")
#make the window visible
taskbar.ClickHiddenSystemTrayIcon("My App")
#When I query the number of windows the app has.
len(app.Windows())
#I get zero windows. There should be at least one window
#because the window is currently visible.
I've also tried the findwindow methods for which I can get a WindowSpecification but it is not connected to any window.
In order for this app to be automatable, the developer had to wrap the NotifyIconWPF in a standard window, conditionally, depending on command line switches. Once this was done, the windows for this application became accessible to pywinauto. It looks to me like Caliburn Micro, intentionally, disabled accessibility for this window class.
I have a very strange problem. The application is based on Qt C++. There is a TabWidget whose tabs are created dynamically. The tab contains QtMainWindow in ActiveX widget. When multiple apps are started, the selected one works fine. But when another tab is selected, it becomes unresponsive.
When I minimize the Application and then maximize again then the tab starts working fine. I tried with setFocus, activateWindow, showNormal and setActiveWindow but nothing is working.
Can somebody help me in this issue?
The likeliest cause of the app becoming unresponsive is something that stalling the execution on the main thread. With running the project from/ or attaching to Visual Studio debugger (better debugger than the one used by Qt Creator) try to get your app in such unresponsive state. Now look at Main Thread in Threads view (select one), also look at Call Stack view. Where does the execution stall?
The log in Output View is also helping to recreate the context of how to get there. You can see Qt and your own debug output there.
While debugging I found that the App was not syncing because of missing WA_Mapped attribute. My problem was just opposite of the below issue. When I used to maximize after minimize, the App used to become responsive. Finally setting the attribute WA_Mapped at different places (trial n error) fixed the issue.
widgets freezing after minimise window
Thanks for #AlexanderVX response.
We are currently testing parts of our application that open in popup windows. These windows are subclasses of TitleWindow. The issue we now run into is that the popups seems to be registered multiple times and that tests are sometimes executed on popups that have already been closed (or so it seems).
I thought this had to do with the way we closed and removed our popups, but I can't really spot any problems there. After looking into the FlexMonkey source code, I saw that there is an explicit check for "TitleWindow" in the ADDED_TO_STAGE handler, after which the popup is added as an application window. But the popup never seems to be removed from the "_windows" collection. As a result, when you open the tree view in FlexMonkey, there are several instances of the same popup window class. This probably also explains why our tests sometimes do not seem to run (visually), but execute and verify correctly, as they are ran on a hidden instance of a popup. I would expect the MonkeyAutomationManager to also listen to REMOVED_FROM_STAGE events and remove the popup when it is closed.
Am I missing something here or is this an (known) issue?
My guess is that it isn't an issue, it's simply that your code isn't properly cleaning the object and removing it from the display list. You also need to remember that garbage collection does not run right after you remove something from the stage. It could be possible that your window, even if it has been removed from the stage is in fact still listening and responding to events.
Have a rather bizarre issue with Flex throwing an error when teh application is running in the background. I use Selenium and SeleniumFlexApi to run various tests against my app. If the browser window is in the foreground or any part of it is visible to teh screen, the test pass as expected. However, if the window is in the background and not visible, I am getting the following error in 1 part of my app.
ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller.
I have a VBOX that creates a number of children and then upon creationComplete(or UpdateComplete, I've tried both) it then needs to remove any of the children that are not visible. Each child has a listener for CreationComplete which checks if the child is visible and if not, adds it to an array which is iterated over when the parent UpdateComplete is fired. I cant seem to find any reason for this behavior and am curious if its an issue with the Flex Component LifeCycle.
The most recent version of the Flash Player (10.1) will automatically "slow down" when minimized. I think it drops to a couple of frames a minute [as opposed to the standard 24 per second for Flex]. I don't know specific number.s This is for performance and 'battery life' reasons.
If there is anything in your app, or in your testing, that requires specific timing or uses a timer, then this will easily break unit tests.
I've heard from other folks that this have other folks that have had issues with this. The best solution I've heard proposed is "Add a flag to turn this off; even if it's only in the debug player." But, there is no solution right now other than "run your tests w/o the app minimized"
Is there a way to force a JavaFX app to repaint itself before proceeding? Similar to a Swing Panel's paint(Graphic g) method (I might be getting the keywords wrong there).
Consider the following example: you write a TicTacToe app along with the AI required for a computer player. You would like the ability to show two computer players duke it out. Maybe you put in a two second pause between computer turns to give it a life-like affect. When you hit your "Go" button, there's a large pause of unresponsiveness (the time it takes for the 9 turns to go by with faked pauses for the computer to 'decide') and then suddenly the app's visual is updated in with the completed game's state.
It seems like JavaFX repaints once processing in the app's thread is finished? I'm not completely sure here.
Thanks!
You are right. JavaFX is event-driven and single-threaded. This means that repaint and event response can not be done simultaneously. Long-running task should be executed on separate thread so they do not block the rendering of the UI, When the task is finished it can sync back to the FX thread by calling FX.deferAction() which will simply execute the code on the main thread.
This won't be the most helpful answer as I have toyed around with JavaFX for all of half a day, but wouldn't you use Timelines, Keyframes, and binding to accomplish your repaints instead of calling them explicitly like you have described?
See this tutorial for an example.
JavaFX's model is to separate you from the painting of the "stuff" on the screen. This is very powerful but is a change from how you might be familiar with.
whaley is correct that the appropriate way of doing this in JavaFX is to make a timeline where the move is done every X seconds and will be drawn at that keyframe.
If you have a question about how to do this, try it and make a new question with some code.