Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [faces-dev] Updating TCK for removal of JSP

I've talked with a colleague who would like to assist/participate in the TCK updates -- Alwin Joseph. He's been very active, working on the Jakarta EE TCK project and knows that end of the TCK tests quite well. I think he could help move this forward.

Since much of this work will entail working with the CI systems, if the other committers think this is a welcome offer, I wonder if it would make sense to consider nominating him for a committer role.

Regardless, if he can help or drive this in any way -- Alwin would be eager to join this effort and I think his experience with the platform TCK will be quite helpful.

One comment I'll offer is, we want to be sure to keep the functional tests separated from the TCK tests. TCK's need to focus only on compatibility and not on implementation details. Whenever TCK tests trend into implementation specifics, trouble ensues. Also, functional tests don't need to be as portable as TCK tests since they are not required to run on other implementations, while TCKs are.

Please help Alwin know how he can best coordinate with this effort.

Cheers,

-- Ed

On 11/6/2020 8:10 AM, Thomas Andraschko wrote:
Hi Arjan,

if you create a new TCK based on Arquillian, i will definitely contribute the existing ones of MyFaces and also write some new ones.
I think 100 tests are a good target for the start, both impls has a good amount of own unittests.
After that we can enhance the TCK with tests for new features or changes.

Best regards,
Thomas

Am Fr., 6. Nov. 2020 um 14:01 Uhr schrieb arjan tijms <arjan.tijms@xxxxxxxxx>:
Hi,

To start with, indeed, the ecosystem isn't that big anymore, so whatever we do we have to take this fact into account. Was it still 2010 with larger amounts of users and available resources, other choices might have been made.

For Mojarra we have multiple versions of tests

1. Integration tests using bash scripts, maven and cargo ( https://codehaus-cargo.github.io/cargo/Home.html)
2. Integration tests using Arquillian
3. Internal tests using Cactus
4. JUnit tests using Mock types

I'm going to delete the Cactus tests. It's simply undoable to either convert or maintain them.

The Arquillian tests are basically identical in setup to the MyFaces tests See https://github.com/eclipse-ee4j/mojarra/tree/master/test2 vs https://github.com/apache/myfaces/tree/master/integration-tests

The cargo/script based tests are very easy to convert to Arquillian (copy/paste, add arquillian runner and deploy annotations), but even that of course takes work. Finally there's 921 unit tests, where everything is mocked.

So where does that leave us? The Arquillian tests of Mojarra and Myfaces could be joined, but we both don't have that many of them. They can be, more or less, instantly rubber stamped as TCK. This is essentially how the CDI, Batch, Validation, and all MP TCKs work. I can spend a few days picking a selection of tests from the cargo reservoir, which should give us a reasonable base. I'm not sure if we will reach 100.

As for the unit tests, we've been working on a servlet/EE runtime implementation called Piranha, that at its lowest level can be used like a unit testing framework. This feels just like using a servlet mock, except that the servlet implementation is the same one the higher level server actually uses. Maybe this is an option for the future to use.

For now though my gut feeling says that if we can agree on rubber stamping the existing Arquillian tests as TCK we're essentially there. There's some specs that don't have a TCK, but those are always trouble, so it's best to have at least a small TCK.

Kind regards,
Arjan










On Fri, Nov 6, 2020 at 9:47 AM Thomas Andraschko <andraschko.thomas@xxxxxxxxx> wrote:
| Maybe we should make a choice here and create a new TCK based on those tests and the Mojarra tests, with a selection of tests taken from the existing TCK which we are reasonably able to convert?

That would be great indeed but also requires a lot of work.
Even if we only do 100 basic tests for the start, setup a framework and 100 tests is a lot of work.

Not sure how you implemented your tests but i like the way how it is in MyFaces.
We start a servlet mock, MyFaces+OWB for each test.
I dont think we could just copy the tests to a TCK.

Does a JakartaEE API need a TCK?
Dont get me wrong, i would like to have one but the work on FacesAPI and the impls is currently way more important. The ecosystem isnt that big anymore.
The less amount we spend into a TCK, the more time we have for the FacesAPI/Impl.

Am Do., 5. Nov. 2020 um 23:14 Uhr schrieb arjan tijms <arjan.tijms@xxxxxxxxx>:
Hi,

On Thu, Nov 5, 2020 at 8:35 PM Thomas Andraschko <andraschko.thomas@xxxxxxxxx> wrote:
Maybe ask the web for new Open source contributors?
TomEE does that and they do at least translations of docs and samples.
TCK is of course ways harder.

Yes, although technically it's not even super hard. It's more that the obscurity of the TCK makes it hard to get into, and hard to run and debug each test individually.

We had some very good contributions from the community to help in converting the spec document, but can we find enough people to convert thousands and thousands of tests?

 
Not sure...
What about ManagedBeans? How many tests (in %) uses it?

A careful estimation is that it's about the same as tests using JSP.

 
Im almost also sure that noone runned the TCK for MyFaces since some years. We have over 1600 unittests which are facelets only and also uses CDI.

Maybe we should make a choice here and create a new TCK based on those tests and the Mojarra tests, with a selection of tests taken from the existing TCK which we are reasonably able to convert?

Kind regards,
Arjan Tijms
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev

_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/faces-dev__;!!GqivPVa7Brio!O2zMp6g5bnkgdUzr1cClngrojIAUuQMuG9jxW9VcbCTmEo9r7XkBmjGV4aFhRMc$

Back to the top