No Simple Way to Replace or Customize DownloadSupport Implementation

[matrei]

I need to use a custom implementation of DownloadSupport in a GebSpec, but I found it quite difficult to replace the default implementation.

The best approach I could come up with was to create a Trait that implements DownloadSupport, essentially duplicating most of the functionality from DefaultDownloadSupport while modifying just one detail: the private URL resolveUrl(Map) method.

If resolveUrl(Map) wasn't private, or if there were a more straightforward way to override or swap the DownloadSupport implementation, this process would be much simpler and more flexible.

[matrei]

The best approach I could come up with was to create a Trait that implements DownloadSupport, essentially duplicating most of the functionality from DefaultDownloadSupport while modifying just one detail: the private URL resolveUrl(Map) method.

By delegating to a inner class extending DefaultDownloadSupport, I managed to get rid of all duplication.
(Thank you @Poundex, by re-reading your suggestion in Groovy Slack I managed to improve this).

[paulk-asert]

@matrei Given your workaround, are you still suggesting a change? Or should we document the idea of your workaround as a hint?

[matrei]

Since this issue has not come up before, it might be an edge case that doesn’t justify changes to Geb, especially considering that a workaround is available.

That said, while exploring a solution, I found it surprising that there’s no straightforward way to plug in a custom implementation. With the current workaround, both Page and Module still use the original DefaultDownloadSupport.

[Poundex]

There should be fixes and changes to Geb here. The workaround only covers the DownloadSupport, and even that shouldn't be necessary. It is a common enough use-case to be testing something far away with the RemoteWebDriver, either if its because TestContainers are in use or some kind of browser farm like Browser Stack. The workaround only addresses the container case and doesn't do anything to make customizing/replacing the other Support classes in Page/Module, either, where Geb is currently demonstrating poor and user-hostile library behaviour.

The first change should be to make the Support fields in Page and Module protected rather than private. This allows sub-classes to implement their own init method and customise or replace these objects. This is the lowest-level fix, it would still need user effort to customise the file downloading but this allows the most complete customisation.

Next, I think that the GebConfig should allow users to define common configuration properties for the Support objects, or supply custom factories for replacing them without having to implement their own init method in Page and Module. This will be a bit more limited but provide a better experience when users are simply trying to pass in some config, and not bring completely custom Support implementations.

Then later on I think a TestContainers extension should join Geb's existing Browser Stack and Sauce Labs built-in extensions (which should be improved, as a quick glance suggests that these have the same problem) so that some common-sense configurations are applied automatically when using certain extensions or Driver types.