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 <[email protected] >: > 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 < > [email protected]>: > >> 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 >> >> >>
