[wildfly-dev] Elytron integration tests in WildFly testsuite

[Jason Greene]

While it’s important that we maintain some legacy coverage, I think its important that our testsuite prioritize coverage of the new vs the legacy, and this can be done organically. New tests should use elytron, and old tests that are updated, which aren’t specifically testing legacy compatibility should be converted over gradually, when convenient. 

My main rationale hare is that code which is continually evolved is more likely to break than that which is largely frozen. It’s really the interop pieces that interact with legacy areas that are of most in need of continued coverage.

> On Dec 2, 2016, at 11:22 AM, James Perkins <jperkins at redhat.com> wrote:
> 
> Instead of duplicating the entire test suite can we just add a new CI job that runs the tests with the *-elytron.xml configuration file? Duplicating the entire testsuite will end in nothing but headaches IMO. Like Kabir mentioned any bug in a test will need to be fixed in two locations.
> 
> On Fri, Dec 2, 2016 at 12:11 AM, Josef Cacek <jcacek at redhat.com <mailto:jcacek at redhat.com>> wrote:
> Hi,
> 
> EAP QE and Elytron Dev teams would like to raise a discussion about how the Elytron integration tests will be added to the WildFly/EAP testsuite.
> We would like to agree on a unified approach across the testsuite, so we don't end up in situation where each component comes with its own "best-fitting" solution.
> 
> We see following requirements:
> 1. new features which come with Elytron need to be covered by integration tests
> 2. existing scenarios have to stay working when Elytron is configured as the default security subsystem
> 3. legacy security subsystem must stay working in parallel
> 
> Our teams came to agreement that the safest way would be to copy whole existing testsuite modules into new ones. E.g.
> 
> cp -r testsuite/integration/basic testsuite/integration/basic-legacy-security
> # + Reconfigure testsuite/integration/basic to use Elytron
> # + Add @Ignore to all tests which fail with Elytron or use directly the old security configuration
> 
> The modules would just live side by side - basic would use Elytron configuration, basic-legacy-security would use configuration similar to (or same as) the current server configuration.
> 
> In the next step we will go through the Ignored tests (the TODO list) for Elytron and rewrite them or report issues if necessary.
> 
> By this way we would keep all the test coverage for legacy security. We would also have all existing scenarios covered (or at least present) for Elytron configuration.
> 
> Are there any objections to this suggestion?
> 
> Thanks,
> 
> -- Josef
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> 
> 
> -- 
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161202/d8d7ca4b/attachment.html