For me the more unit tests the better no matter what the technology :)
On 10/7/2022 7:15 AM, Werner Punz wrote:
Hi thanks, then I will prepare a pull request. Expect it early/mid
next week.
You still can decide whether you want to take it in or not, then.
Werner
Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware
<melloware...@gmail.com>:
I am totally find without Arquillian as well.
On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote:
For me it's fine without Arquilian
Udo
Am 07.10.22 um 09:56 schrieb Werner Punz:
Hi, given I have not gotten any answer!
Do you guys want the tests within MyFaces or is Arquilian an
absolute must?
Werner
Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz
<werner.p...@gmail.com>:
Hi,
I just wanted to get feedback on the following:
Atm we have a barebones Ajax integration test in our
integration test system, derived from my github based
integration testsuite.
Problem is
a) It is barebones, and basically just the basic tests,
which is mostly test 1 of my suite, also it needs lots of
code for maintenance.
b) The current aquilian installation makes problems ( have
not spent too much time fixing this, i just filed a
bugreport for now)
c) The new codebase uses already a ton of mocha based unit
tests on ts level
I have my own set of atm 19 integration tests, which I run
against my codebase. The issue is, that this testcase uses
mocha in the pages to collect the test data and to run the
tests with a well known api.
And in the backend a server is running providing beans and
response.
The test results are collected client side.
Given the troubles I had with Aquilian, I have extended my
codebase on Github so that the tests automatically run with
an embedded chrome via the maven frontend plugin
and also the frontend plugin hooks the test results into the
maven build
So basically internally maven starts an embedded tomcat viay
the exec plugin and the frontend plugin pushes an embedded
windowless chrome against this code to run the tests and
collect the results, and reports them back to Maven
in the integration test phase
...
[INFO]
http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf
[INFO] Page test10-doubleeval Successes:
[INFO] => Regression test for double eval on a single script
element
[INFO] => Runs the double eval test
[INFO] ✔ double evaluation of embedded scripts testcase
(281ms)
[INFO]
http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf
[INFO] Page test11-scriptblocks Successes:
[INFO] => Script blocks in various formats
[INFO] => Performs a script bloc test
...
[INFO] => Execute none handling
[INFO] => SPEC HAS NO EXPECTATIONS runs an execute request
with execute @none
[INFO] ✔ execute parameter test (281ms)
[INFO]
[INFO]
[INFO] 19 passing (23s)
[INFO]
[INFO]
[INFO] --- maven-failsafe-plugin:2.12:verify (default) @
IntegrationJSTest ---
This how it looks if all tests have passed
or in case of a failure:
[INFO] 18 passing (23s)
[INFO] 1 failing
[INFO]
[INFO] 1) Integration Testsuite MyFaces
[INFO] testing viewRoot:
[INFO]
[INFO] AssertionError: expected false to be true
[INFO] + expected - actual
[INFO]
[INFO] -false
[INFO] +true
[INFO]
[INFO] at Context.<anonymous>
(src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28)
[INFO] at processTicksAndRejections
(node:internal/process/task_queues:96:5)
[INFO]
[INFO]
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
The config is as follows:
The advantage is that the tests are now way easier to write
and hook themselves perfectly into the client side unit test
system.
Next advantage you also can run the tests directly in your
browser and you also can show a browser instead of an
headless embedded chrome.
We also would get 17-18 additional integration tests "for
free" in the myfaces codebase, simply because I have them
already written a long time ago.
The disadvantage is (whether this really is one) we bypass
Aqulian in favor of the frontend plugin node and mocha.
I have this system working now, but as usual would perform
another round of cleanups before merging it into myfaces,
after the RC3 jsf_ts merge.
So what´s your opinion, shall we add those tests to the
codebase? I do not have any problem, to leave them where
they are, they work fine for my purposes.
Werner
