From what I see, there is no support for other protocol besides HTTP.
All the WebDriver implementations despite HtmlUnit extends from
RemoteWebDriver, which uses the CommandExecutor interface for
communicate with the server. In theory, the CommandExecutor
implementation is pluggable, but in reality, all the implementations
uses HTTP based command executor, which uses Apache HTTP Client under
the covers to communicate with the selenium server and they don't
provide straightforward way to use something different.
Not sure if there is some performance improvement in newest version? We
use the WebDriver version, which uses selenium 2.53.0. Now there is
already version 3 available.
Marek
On 08/06/17 09:20, Vaclav Muzikar wrote:
I agree with Marek - I don't think it would do any good for us as
the
default browser.
Imho the new headless mode doesn't make a much difference for us - the
Chrome would be working on the same principle as before (through
ChromeDriver).
Moreover, Chrome and ChromeDriver would need to be
downloaded/installed from external sources - yet, this could be
perhaps solvable with Maven (at least ChromeDriver as it's in the
Maven repo).
On Wed, Jun 7, 2017 at 9:53 PM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Just a note, the main reason why htmlUnit web driver is so faster than
other browsers is, that it is fully embedded in the same JVM like
tests.
There is no additional overhead in the communication with other
processes. The only exception are the HTTP requests for the
communication with the tested Keycloak server and adapters.
On the other hand, the other web driver implementations, including
phantomJS, are using external process and there is remote selenium
server with which the webDriver needs to communicate. It means
that all
the webDriver calls including the most simple (like
driver.getTitle() )
need to send additional HTTP request to the remote selenium server
under
the covers. All of this adds an additional overhead.
I suspect that headless chrome will also use remote selenium, hence I
don't expect that performance will be much better comparing to
phantomJS. But maybe I am wrong..
Marek
On 07/06/17 12:14, Stian Thorgersen wrote:
> We've picked Htmlunit as the default browser to run tests with
due to it
> being the fastest. Downside is that it simply doesn't work very
well for
> all tests, especially those heavy on the javascript side of
things like
> testing the JavaScript adapter and admin console.
>
> Just saw that Chrome is actually bringing a headless option to
Chrome 59
> [1]. This is really nice as it allows headless testing with a
real browser,
> not just an emulated browser.
>
> Ideally if this is fast we could use it as the default browser
instead of
> htmlunit. Obviously waiting until it's released on all
platforms. If it's
> not as fast as htmlunit then maybe there is a compromise.
>
> The default browser would still be htmlunit. Then individual
tests could be
> marked (with an annotation on the class or on the WebDriver
field). Those
> marked would use Chrome in headless mode instead of htmlunit.
Obviously
> -Dbrowser would continue to override the browser in either case.
>
> Thoughts? Anyone interested in giving the new headless Chrome
option a spin
> and evaluating how fast it is compared to htmlunit?
>
> [1]
https://developers.google.com/web/updates/2017/04/headless-chrome
<
https://developers.google.com/web/updates/2017/04/headless-chrome>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
--
Václav Muzikář
Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.