Currently, in the docker test framework, the first request to the XWiki instance is done using an HTTP client, which mean the wiki descriptor is initialized with what the HTTP client uses. In practice that means that, when executing a test locally, localhost:8080 for a xjetty setup, and localhost:<available port> for docker based application servers. This is also what is used for REST access (also based on an HTTP client).
But the domain used for the browser access (and so, in selenium) is quite different: since the browser runs in docker, it cannot use localhost and have to use a domain to access the host’s localhost (so host.testcontainers.internal:8080 for xjetty, and host.testcontainers.internal:<available port> for docker based application servers).
What it means for the tests is that URL generated using what can be found in the wiki descriptor (generally absolute URL generated in non HTTP threads, like mails, or any code which does not reuse the source URL for various reasons).
AFAIK, the current situation happened naturally, when moving to docker, without any real discussion, so here is the discussion.
I guess the main question is: is it OK that the standard domain configured in the wiki descriptor is not the same as the one used in the browser, or should we fix it ?
having the browser use something different from what is in the wiki descriptor is not the most common use case
On the other hand, even if it was not really done on purpose, it’s a good way to make sure that we do properly support accessing the same XWiki instance with completely different domains, which is a feature we use (for example in a clustering setup to access each node separately: think about xwiki.org and xwikiorg-node1.xwikisas.com/xwikiorg-node2.xwikisas.com).
To make things easier for tests, I propose to introduced in UITest a way to choose between BROWSER and HTTPCLIENT in the wiki descriptor (meaning setting the right metadata in the wiki descriptor depending on this configuration).
But we still need to decide what should be the default:
a. keep the current behavior (so HTTPCLIENT in UITest)
b. switch the wiki descriptor to the browser base URL (so BROWSER in UITest)
So WDYT ?
+1 for the new UITest helper
Honestly I don’t know which one to choose, so I will let others decide. It would definitely make a lot more sense to have the browser and the wiki descriptor be in sync, since it’s by far the main use case. But I’m reluctant to abandon all those “free” validations of that async use case.
Really interested in other opinions as well.
I’m currently +1 to make the default browser base URL, but I also agree that we shouldn’t lost the coverage of http client URL too.
Well if I understand properly the URL built using the info of the wiki descriptor currently don’t work in our test since they’re using localhost which cannot be reached from the browser. So IMO it would make sense to always rely on the browser URL by default.
Not sure exactly what you mean by that: the fact we initialize the wiki without accessing it through a browser request? What does it change?
Expressing it like this is a bit reductive, it does not work through the browser, but it does work (we also use the HTTP client in many tests, generally for setup). It’s not like it was some unusable junk (in which case this thread would not exist).
As I said, the question is should we give priority to the browser access or to the direct HTTP access.
As explain in the first message, the wiki descriptor is configured with a domain/port which have nothing to do with those we use in the browser when executing the tests. The reason it works is because the source URL is reused when generating absolute URLs (ajax requests would fail if we were using the configured domain instead of the source URL, for example) and this is an important feature which keeps working, at least partly, thanks to that test setup situation I suspect.
Hmmm so maybe the question is not much about the default, but about the capability in our test framework to be able to switch from one behaviour to the other and check it keeps working. Basically for some tests we know already we need to rely on Browser (because of mail URL etc), but for most of our tests browser or test client should work.
So indeed then it would make sense to keep HttpClient by default just for ensuring it keeps working. Another option could be to switch to Browser by default which feels conceptually slightly better, but then we should be able to execute from time to time a subset of the tests with HttpClient. In any case it would be probably good to have the option available also in the test fwk arguments.
It’s not really clear to me what you are suggesting here. Are you just confirming your +1 for proposal 1. or are you saying the switch at test class level is not enough, and we should introduce some new annotation for that choice at test method level, instead of just having two test classes when you have two use cases ?
No, I’m confirming I’m +1 to have this as test class level, but I’m wondering if we shouldn’t also expose it in the docker test arguments like we have for the servlet engine, etc. To be able to use `-Dxwiki.test.ui.wikiDescriptorUrlSource=browser` basically.
Being added to UITest also imply introducing a system property IMO, do we have UITest properties which don’t have a corresponding command line version ?
We could move one or two (one Chrome, one Firefox maybe) environment test configurations to use the HttpClient setup by default (for tests not indicating the setup explicitly).
Actually, UITest apply to the whole module, by definition, and not just the test class. So I propose to also introduce a dedicated annotation to control that also at a lower level (class or test method).