Discussion: Development and usage under macOs (maybe Linux, Win)

[Brice Dutheil]

Hi, I have a question regarding the usability of this plugin on small screen during test/debug.

I am developing on macOs, where the cursor is controlled by the test robot. Maybe the other OS have similar behavior.

Here's a few issues I noted.

1. When the tests are starting, the robot borrows the mouse pointer which prevents the usage of the mouse for other matters while a test suite is running otherwise tests may break. Moreover the tests can be very long this makes the machine unusable for a while.
2. Regularly the Main window gets behind another window/app – a browser or another IntelliJ window – if this is the case the pointer will trigger actions on the said window/app.
3. When debugging some components like menu, heavy weight window, etc. looses focus, and in the next step of the debug they are not anymore visible via the robot Dom, this makes the debug clunky, even tedious.
4. The window can move screens which breaks tests, eg closing the project can bring the welcome frame but on a different frame, which breaks the follow-up actions because the mouse pointer didn't move.

Non exhaustive list.

How are you working around those?

---

Version : 0.11.7
macOs : 11.6

[eugene nizienko]

When the tests are starting, the robot borrows the mouse pointer which prevents the usage of the mouse for other matters while a test suite is running otherwise tests may break. Moreover the tests can be very long this makes the machine unusable for a while.

Usually, local run is used for writing and debugging tests. After that tests may be executed on CI. You can check our Github Actions configs. Also, it is possible to create a docker image with the Idea and the robot-server plugin, map robot port outside and launch UI tests the way as it would be headless.

Regularly the Main window gets behind another window/app – a browser or another IntelliJ window – if this is the case the pointer will trigger actions on the said window/app.

It is a good idea to run tests in a clean environment, such as a Github Actions machine, docker container or virtual machine.

When debugging some components like menu, heavy weight window, etc. looses focus, and in the next step of the debug they are not anymore visible via the robot Dom, this makes the debug clunky, even tedious.

Indeed, there are situations when you have to have the Idea in focus to catch correct hierarchy. For that purpose, there is a little trick in the hierarchy page. You can click at Update page in 5 seconds, switch to the Idea and open popup or heavyweight window you need to catch, hierarchy page will be updated on the background and will catch UI hierarchy snapshot.

The window can move screens which breaks tests, eg closing the project can bring the welcome frame but on a different frame, which breaks the follow-up actions because the mouse pointer didn't move.

I'm afraid I'm not quite caught the problem. In case you mean when failed test causes next tests to fail, then I can suggest using some sort of @AfterAll/@AfterEach steps to make the Idea return to the initial state. For instance, you can cancel all dialogs there and close the project.

[Brice Dutheil]

1. Usually, local run is used for writing and debugging tests. After that tests may be executed on CI. You can check our Github Actions configs. Also, it is possible to create a docker image with the Idea and the robot-server plugin, map robot port outside and launch UI tests the way as it would be headless.

   It is a good idea to run tests in a clean environment, such as a Github Actions machine, docker container or virtual machine.

   Yes running in CI is definitely the goal but I'm more focusing this when developing those tests or debugging them (so on a local machine). Maybe there's no other way, yet that would be awesome if it could work without requiring the actual mouse pointer.

2. Indeed, there are situations when you have to have the Idea in focus to catch correct hierarchy. For that purpose, there is a little trick in the hierarchy page. You can click at Update page in 5 seconds, switch to the Idea and open popup or heavyweight window you need to catch, hierarchy page will be updated on the background and will catch UI hierarchy snapshot.

   Yes I have identified the browser trick. But when debugging this is not possible because the focus is on the debugger not on the debugee process.

3. The window can move screens which breaks tests, eg closing the project can bring the welcome frame but on a different frame, which breaks the follow-up actions because the mouse pointer didn't move.

   I'm afraid I'm not quite caught the problem. In case you mean when failed test causes next tests to fail, then I can suggest using some sort of @AfterAll/@AfterEach steps to make the Idea return to the initial state. For instance, you can cancel all dialogs there and close the project.

   Hi, sorry I wasn't clear. What I meant is that in a single test scenario, one might have to open/close multiple dialogs. And I noticed that on a local machine with multiple screens, the IntelliJ windows can be opened in different displays (the internal or the external). And the mouse position isn't always in sync with the window position of the new dialog/window. So the mouse move to the wrong offset because the window has been opened on another display. To work around those I had to script defensively, trying to require the component again to get the updated position.