Testing JavaFx View Question

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Testing JavaFx View Question

I am having trouble with this scenario:

- I have a view in my app defined with FXML
- I have a class (let's call it MyViewManager) that performs modifications in the view before it is being shown (like adding menus, and so on).
- I am using TestFX to test the view.

The problem I have is that the view is shown as defined by the fxml and I am unable to find a way to allow MyViewManager to modify it before it is being shown on the screen. Is there a way to do this?
I tried overriding the before method in GriffonTextFXRule but it does not work: the view is initialized and shown before this method is executed. I also tried doing the customization in the constructor of the test class, but MyViewManager is not injected before GriffonTextFXRule runs.
I wish testing could be easier in Griffon
Also, when I debugged the test to learn how the internals work, I noticed that line 101 in GriffonTestFXRule does not always work. Sometimes I set breakpoints in different parts of the code to try to figure out how to solve a problem (like this case) and that is an operation that might take a while (I'm slow, what can I say...). The thing is that eventually the test window is shown on the screen, but the await() operation on line 101 waits forever...
Anyway, any comments on how to solve this problem will be appreciated!
Reply | Threaded
Open this post in threaded view

Re: Testing JavaFx View Question

Hi Marcelo,

That's correct, `GriffonTestFXRule.before` is invoked after the chosen Window becomes visible. You can however inject a custom `MyViewManager` instance on the test case, for example

  private MyViewManager viewManager = new MyViewManagerImpl() { ... }

This works best assuming `MyViewManager` is an interface. More information about @BindTo can be found in the guide http://griffon-framework.org/guide/2.10.0/#_overriding_module_bindings

What's going on when `GriffonTestFXRule` is used? AFAIK TestFX either initializes a "fake" application (a subclass of javafx' Application) and hooks in the nodes into the main stage _or_ initializes a custom subclass of javafx's Application that you provide. Griffon chose the latter approach as this allows initialization of a full Griffon application up to a certain point. This means the only way to customize the application's behavior is to use the DI container, thus the usage of @BindTo or module overrides is the way to go.