You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2022/10/06 14:22:38 UTC
faces_ts integration tests
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
Re: faces_ts integration tests
Posted by Werner Punz <we...@gmail.com>.
Regarding my mail, never mind, I now have write access. I missed the
linking step of linking both accounts, when I registered
into id.apache.org
Problem solved now.
Werner
Am Mi., 12. Okt. 2022 um 08:23 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> Hi regarding the plan.
> Following: I would merge those tests the same time I will merge the new
> scripts which will be around RC3 as current status.
> The reason is, one of the tests (the api decoration test) fails on the old
> codebase after the namespace renaming.
>
> Given we are on our way out regarding the old codebase, it does not make
> sense to fix this anymore.
> If there is a need for it for the RC2 then I can do it, but as you can
> guess, I could spend the time elsewhere better.
>
> For now the tests run against the github version of the Ajax code (via npm
> include)
> but at the final merge I will target it towards our embedded scripts.
> (imports.xhtml, has the includes, you can redirect it yourself, have been
> testing the embedded version constantly via custom builds
> from my 4456 feature branch)
>
> I did this so that the build is not broken if the integration tests are
> triggered.
> If that is ok with you guys, we will postpone the merge until we take
> everything in.
>
> Also, I have a small infrastructural problem. I usually committed over
> Gitlab, I cannot see a merge button for my pull requests on github, despite
> having my username entered into my github settings on my apache account.
> Does anyone know what the problem could be?
> (my github account does not target my apache address, but my normal mail,
> so I thought, adding it in the apache account settings should suffice)
>
>
>
> Am Di., 11. Okt. 2022 um 11:34 Uhr schrieb Werner Punz <
> werner.punz@gmail.com>:
>
>> I just dropped a pull request on the 20 integration tests:
>> https://github.com/apache/myfaces/pull/331
>>
>> The tests run automatically from the maven build as usual, but thing is,
>> 19 tests more than before but no aquilian (mocha and and embedded tomcat is
>> used now)
>>
>> I pulled the old ajax tests, because there was nothing, which is not
>> covered by the new tests.
>> Also it is now way easier to write tests, with less code.
>> readme.md is included which explains everything in more detail
>>
>>
>> Am Fr., 7. Okt. 2022 um 13:23 Uhr schrieb Melloware <
>> mellowaredev@gmail.com>:
>>
>>> 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 <
>>> mellowaredev@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.punz@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
>>>>>
>>>>>
>>>>>
Re: faces_ts integration tests
Posted by Werner Punz <we...@gmail.com>.
Hi regarding the plan.
Following: I would merge those tests the same time I will merge the new
scripts which will be around RC3 as current status.
The reason is, one of the tests (the api decoration test) fails on the old
codebase after the namespace renaming.
Given we are on our way out regarding the old codebase, it does not make
sense to fix this anymore.
If there is a need for it for the RC2 then I can do it, but as you can
guess, I could spend the time elsewhere better.
For now the tests run against the github version of the Ajax code (via npm
include)
but at the final merge I will target it towards our embedded scripts.
(imports.xhtml, has the includes, you can redirect it yourself, have been
testing the embedded version constantly via custom builds
from my 4456 feature branch)
I did this so that the build is not broken if the integration tests are
triggered.
If that is ok with you guys, we will postpone the merge until we take
everything in.
Also, I have a small infrastructural problem. I usually committed over
Gitlab, I cannot see a merge button for my pull requests on github, despite
having my username entered into my github settings on my apache account.
Does anyone know what the problem could be?
(my github account does not target my apache address, but my normal mail,
so I thought, adding it in the apache account settings should suffice)
Am Di., 11. Okt. 2022 um 11:34 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> I just dropped a pull request on the 20 integration tests:
> https://github.com/apache/myfaces/pull/331
>
> The tests run automatically from the maven build as usual, but thing is,
> 19 tests more than before but no aquilian (mocha and and embedded tomcat is
> used now)
>
> I pulled the old ajax tests, because there was nothing, which is not
> covered by the new tests.
> Also it is now way easier to write tests, with less code.
> readme.md is included which explains everything in more detail
>
>
> Am Fr., 7. Okt. 2022 um 13:23 Uhr schrieb Melloware <
> mellowaredev@gmail.com>:
>
>> 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 <
>> mellowaredev@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.punz@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
>>>>
>>>>
>>>>
Re: faces_ts integration tests
Posted by Werner Punz <we...@gmail.com>.
I just dropped a pull request on the 20 integration tests:
https://github.com/apache/myfaces/pull/331
The tests run automatically from the maven build as usual, but thing is, 19
tests more than before but no aquilian (mocha and and embedded tomcat is
used now)
I pulled the old ajax tests, because there was nothing, which is not
covered by the new tests.
Also it is now way easier to write tests, with less code.
readme.md is included which explains everything in more detail
Am Fr., 7. Okt. 2022 um 13:23 Uhr schrieb Melloware <mellowaredev@gmail.com
>:
> 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 <
> mellowaredev@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.punz@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
>>>
>>>
>>>
Re: faces_ts integration tests
Posted by Melloware <me...@gmail.com>.
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
> <me...@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
>>> <we...@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
>>>
>>>
Re: faces_ts integration tests
Posted by Werner Punz <we...@gmail.com>.
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 <mellowaredev@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.punz@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
>>
>>
>>
Re: faces_ts integration tests
Posted by Melloware <me...@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
>> <we...@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
>>
>>
Re: faces_ts integration tests
Posted by Udo Schnurpfeil <lo...@apache.org>.
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
> <we...@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
>
>
Re: faces_ts integration tests
Posted by Werner Punz <we...@gmail.com>.
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.punz@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
>
>
>