<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 2, 2016, at 11:22 AM, James Perkins <<a href="mailto:jperkins@redhat.com" class="">jperkins@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Dec 2, 2016 at 12:11 AM, Josef Cacek <span dir="ltr" class=""><<a href="mailto:jcacek@redhat.com" target="_blank" class="">jcacek@redhat.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
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.<br class="">
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.<br class="">
<br class="">
We see following requirements:<br class="">
1. new features which come with Elytron need to be covered by integration tests<br class="">
2. existing scenarios have to stay working when Elytron is configured as the default security subsystem<br class="">
3. legacy security subsystem must stay working in parallel<br class="">
<br class="">
Our teams came to agreement that the safest way would be to copy whole existing testsuite modules into new ones. E.g.<br class="">
<br class="">
cp -r testsuite/integration/basic testsuite/integration/basic-<wbr class="">legacy-security<br class="">
# + Reconfigure testsuite/integration/basic to use Elytron<br class="">
# + Add @Ignore to all tests which fail with Elytron or use directly the old security configuration<br class="">
<br class="">
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.<br class="">
<br class="">
In the next step we will go through the Ignored tests (the TODO list) for Elytron and rewrite them or report issues if necessary.<br class="">
<br class="">
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.<br class="">
<br class="">
Are there any objections to this suggestion?<br class="">
<br class="">
Thanks,<br class="">
<br class="">
-- Josef<br class="">
______________________________<wbr class="">_________________<br class="">
wildfly-dev mailing list<br class="">
<a href="mailto:wildfly-dev@lists.jboss.org" class="">wildfly-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/<wbr class="">mailman/listinfo/wildfly-dev</a><br class="">
</blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">James R. Perkins</div><div class="">JBoss by Red Hat</div></div></div></div></div>
</div>
_______________________________________________<br class="">wildfly-dev mailing list<br class=""><a href="mailto:wildfly-dev@lists.jboss.org" class="">wildfly-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</div></blockquote></div><br class=""><div class="">
--<br class="">Jason T. Greene<br class="">WildFly Lead / JBoss EAP Platform Architect<br class="">JBoss, a division of Red Hat
</div>
<br class=""></div></div></body></html>