+1000 To a conformance testsuite. It would be much less work to have a
single testsuite that can be used regardless of adapter.
On 10 May 2017 at 11:46, Sebastien Blanc <sblanc(a)redhat.com> wrote:
Yes it's a great idea and I tried to word the specs as test
requirements
"Should ..." .
Regarding unified tests apps, yes, something around functional test could
do it.
For instance, if you look at these tests
https://github.com/keycloak/keycloak-quickstarts/blob/
master/service-jee-jaxrs/src/test/java/org/keycloak/quickstart/jaxrs/
ArquillianServiceJeeJaxrsTest.java
, even if it's written in Java, it's pretty agnostic against which secured
back end it runs ... Some there is definitely some space for that.
But first, let's make sure we have a complete and curated list of
specifications.
On Wed, May 10, 2017 at 11:20 AM, Vaclav Muzikar <vmuzikar(a)redhat.com>
wrote:
> +1
> I think that's a great idea! However, not sure about implementation
> possibilities for such conformance testsuite since the adapters are often
> platform/framework/language specific. Perhaps some unified test app(s)
> which could be protected by any adapter?
>
> On Tue, May 9, 2017 at 11:00 PM, Bruno Oliveira <bruno(a)abstractj.org>
> wrote:
>
> > This is a great start Sebi. And I think we can always change along the
> > way.
> >
> > I was just thinking here about something for the future, maybe. A way
to
> > certify our Keycloak adapter's implementation. This idea came from
> > OpenID connect certification[1].
> >
> > Why? In this way people could run conformance tests against our server
> > and make sure that their implementation is still compatible with the
> > latest releases of Keycloak. This also would enable us to know which
> > project is stable or not.
> >
> > I know this could be a lot of work, but maybe something we could
> work/take
> > into
> > consideration for further releases.
> >
> > [1] -
http://openid.net/certification/testing/
> >
> > On 2017-05-09, Sebastien Blanc wrote:
> > > Hi !
> > >
> > > I've started this sheet [1] that attempt to list all the features and
> > > checks that a Keycloak adapter should support + a support matrix for
> our
> > > existing adapters.
> > >
> > > Feel free to add any missing feature, it's a really early version
> > started a
> > > few hours ago,
> > >
> > > Sebi
> > > [1]
> > >
https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHOR
> > qIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
>
>
> --
> Václav Muzikář
> Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev