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(a)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(a)redhat.com
<mailto:jcacek@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)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