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
>
>
>

Reply via email to