1:42 a.m.
Hello! Thanks for this effort Harald. I really like the motivation.
I took a look at the PoC and tried to run it with Podman (IIRC officially
unsupported by TestContainers so mileage may vary). It took up to 30
seconds to initialize containers already downloaded from quay.io for a test
class. I'm also not a big fan of a common parent class for each test class
and I would prefer to have an additional few lines of code in each test
class. Otherwise it runs fine.
Thanks to having multiple Maven modules with tests it is currently possible
to parallelize the run of individual modules in Jenkins matrix
configuration. Is it possible to download all needed containers in a
preparation step to not have to do this in every matrix configuration?
Initialization like this would add some execution time to the test run.
IMHO it is hard to say if stability will improve in the usual large scale
HAL tests are running in. Jenkins nodes we use are virtualized. I can
imagine that using TestContainers may improve stability in terms of
dependencies - now we would be sure browser and VNC are always present and
properly configured but that's not a common problem from my experience. How
would using TestContainers improve stability?
If all the changes you mentioned are aimed only at upstream (since you
mention GH actions and TeamCity), would it be possible to still run tests
without TestContainers?
Does the TestContainers solution suppose to replace existing testsuite?
Thanks!
On Mon, Jan 31, 2022 at 7:43 PM Harald Pehl <hpehl(a)redhat.com> wrote:
TLDR;
I've setup a PoC [1] for an alternative way to test the HAL management
console.
The PoC is based on Testcontainers [2], Arquillian [3] and JUnit 5.
Although
this is primarily intended for UI testing, the usage of Testcontainers
could
also be interesting for the WildFly test suite.
---
The existing HAL test suite [4] is a rich test suite for the HAL management
console. It contains 300+ UI tests based on Arquillian [3].
The UI tests require a browser and a running WildFly instance as an
execution
environment. This makes is hard to run the tests on a CI server. Another
issue
is that the tests are not very stable and often run into timeouts. To
execute
the complete test suite you need a stable environment.
Recently I came across Testcontainers [2], which provide a nice API to
start
arbitrary containers before / after (all) unit tests. The library also
provides
an elegant way to start and use browsers in remote web containers.
Therefore, I decided to implement a PoC which provides an alternative and
more stable way to test the HAL management console. Tests are self
contained and can run in CI environments such as GH Actions or Teamcity.
At the same time the new approach has to be compatible with the existing
test
suite. Tests should be runnable w/o major code changes using the new
approach.
The result is [1]. If you're interested, feel free to take a look and let
me
know what you think!
---
[1] https://github.com/hpehl/manatoko
[2] https://www.testcontainers.org/
[3] http://arquillian.org/arquillian-graphene/
[4] https://github.com/hal/testsuite.next
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Jan (Honza) Kasik
Quality Engineer, EAP QE