Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite?

Jaikiran Pai-2
I was working on a change and a testcase related to one of the JIRAs
open in WFLY and happened to notice that we now have a
testsuite/integration/legacy-ejb-client module. It looks like this
module has testcases that are also part of testsuite/integration/basic -
i.e. copy pasted. So we now have 2 copies of a testcase for example
EJBClientAPIUsageTestCase. What's the guideline when dealing with these
testcases? Should both these testcases be kept up-to-date with any
changes to the behaviour of the server interaction with the remote
client? The context of my question is this PR
https://github.com/wildfly/wildfly/pull/10466

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite?

jtgreene
Administrator
Hi Jaikiran,

You probably already noticed alot of this, but just to make sure everyone is on the same page the legacy ejb client is for the 3.x branch of the ejb client code based, and the current client is the 4.x branch. The 3.x branch is the same as the 2.x branch, but with updates to synchronize dependencies and integrate with elytron capabilities. So 3.x is intended to be 100% API compat with 2.x. 4.x on the other hand has dropped some elements of the API that no longer make sense and added new APIs. So 3.x is unlikely to be enhanced further, with just bug fixes, and all new work going into 4.x. Since most access patterns port without issue, we expect 3.x will have fairly low usage, and will one day be phased out. 

So basically the only reason to add test coverage with 3.x use (legacy-ejb-client) is if there is a bug that affects it, or a change was made that is likely to impact its operation. Since 4.x is protocol compat with 3.x though, changes on the 4.x server side do need to factor in 3.x client behavior.

-Jason

On Sep 12, 2017, at 12:37 AM, Jaikiran Pai <[hidden email]> wrote:

I was working on a change and a testcase related to one of the JIRAs
open in WFLY and happened to notice that we now have a
testsuite/integration/legacy-ejb-client module. It looks like this
module has testcases that are also part of testsuite/integration/basic -
i.e. copy pasted. So we now have 2 copies of a testcase for example
EJBClientAPIUsageTestCase. What's the guideline when dealing with these
testcases? Should both these testcases be kept up-to-date with any
changes to the behaviour of the server interaction with the remote
client? The context of my question is this PR
https://github.com/wildfly/wildfly/pull/10466

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite?

Jaikiran Pai-2

Thanks Jason, that answers my question. I'll rework/rethink that PR to account for the 3.x client behaviour.

-Jaikiran


On 12/09/17 11:22 AM, Jason Greene wrote:
Hi Jaikiran,

You probably already noticed alot of this, but just to make sure everyone is on the same page the legacy ejb client is for the 3.x branch of the ejb client code based, and the current client is the 4.x branch. The 3.x branch is the same as the 2.x branch, but with updates to synchronize dependencies and integrate with elytron capabilities. So 3.x is intended to be 100% API compat with 2.x. 4.x on the other hand has dropped some elements of the API that no longer make sense and added new APIs. So 3.x is unlikely to be enhanced further, with just bug fixes, and all new work going into 4.x. Since most access patterns port without issue, we expect 3.x will have fairly low usage, and will one day be phased out. 

So basically the only reason to add test coverage with 3.x use (legacy-ejb-client) is if there is a bug that affects it, or a change was made that is likely to impact its operation. Since 4.x is protocol compat with 3.x though, changes on the 4.x server side do need to factor in 3.x client behavior.

-Jason

On Sep 12, 2017, at 12:37 AM, Jaikiran Pai <[hidden email]> wrote:

I was working on a change and a testcase related to one of the JIRAs
open in WFLY and happened to notice that we now have a
testsuite/integration/legacy-ejb-client module. It looks like this
module has testcases that are also part of testsuite/integration/basic -
i.e. copy pasted. So we now have 2 copies of a testcase for example
EJBClientAPIUsageTestCase. What's the guideline when dealing with these
testcases? Should both these testcases be kept up-to-date with any
changes to the behaviour of the server interaction with the remote
client? The context of my question is this PR
https://github.com/wildfly/wildfly/pull/10466

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev