[keycloak-dev] Migrate testsuite

Stan Silvert ssilvert at redhat.com
Fri Apr 15 08:47:11 EDT 2016 

OAuthClient is now migrated to the new testsuite and merged to master.  
PR for 1.9.x is pending.

Also new is an abstract base class that should be helpful for migrating 
tests.

org.keycloak.testsuite.TestRealmKeycloakTest provides a method called 
configureTestRealm(RealmRepresentation testRealm). Override this method 
to do the same kind of configuration performed in the old testsuite.  
(Note: "testRealm" was referred to as "appRealm" in the old testsuite.)

OLD TESTSUITE:
https://github.com/keycloak/keycloak/blob/1.8.x/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/TokenIntrospectionTest.java#L63-L85

EQUIVALENT CODE IN NEW TESTSUITE:
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/oauth/TokenIntrospectionTest.java#L80-L102

On 4/12/2016 3:11 PM, Bruno Oliveira wrote:
> Nice! Meanwhile answering my own question, seems like
> transforAccessToken is required for that test case work.
>
> On Tue, Apr 12, 2016 at 3:48 PM, Stan Silvert <ssilvert at redhat.com> wrote:
>> On 4/12/2016 12:16 PM, Stan Silvert wrote:
>>> On 4/12/2016 10:38 AM, Bruno Oliveira wrote:
>>>> Good morning,
>>>>
>>>> I'm looking at this test case
>>>>
>>>> https://gist.github.com/abstractj/8d3f1ca74a0dfb4f58f7810c519c6272#file-accesstokentest-java-L90
>>>>
>>>> Although, it fails here
>>>>
>>>> https://gist.github.com/abstractj/8d3f1ca74a0dfb4f58f7810c519c6272#file-accesstokentest-java-L112
>>>>
>>>> My feeling is the fact that I don't have this method
>>>>
>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/services/src/main/java/org/keycloak/protocol/oidc/mappers/RoleNameMapper.java#L91
>>>>
>>>> My question is: Is this something that could be solved with
>>>> OAuthClient or is just the matter of migrate transformAccessToken?
>>> I don't know the answer, but I can tell you where I am with OAuthClient.
>>> It appears to be all working now.
>>>
>>> I've migrated TokenIntrospectionTest and ClientTest, which use several,
>>> but not all, of the OAuthClient methods.  All of the tests in those classes
>>> will pass.
>>>
>>> However, TokenIntrospectionTest will only pass if you run each test
>>> individually.  The reason they won't run as a group is because
>>> AssertEvents.clear() is not working.  It took awhile but I finally figured
>>> out why.  The problem is that AssertEvents.clear() is trying to call
>>> realmResource.clearEvents().  But there is a servlet filter installed and
>>> that is where the events are actually read from.    So
>>> realmResource.clearEvents() doesn't have any effect on the event cache being
>>> read during the test.
>>>
>>> There are two ways we could fix this.  One is to get rid of the filter and
>>> make AssertEvents completely rely on the adminClient. The other way is to
>>> add a clear() method to EventListenerProvider. That way, all event listeners
>>> will be notified to clear out their event caches.
>> Actually, there is a third option.  I added a second "command" to the
>> AssertEventsServletFilter.  Now it can respond to both /event-queue and
>> /clear-event-queue.  Updated AssertEvents to use clear-event-queue and
>> everything now works.  PR coming soon.
>>
>>
>>> Bruno, for now just be aware that AssertEvents.clear() isn't working.
>>>>
>>>> On Thu, Apr 7, 2016 at 2:32 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>>
>>>>> On 7 April 2016 at 19:27, Stan Silvert <ssilvert at redhat.com> wrote:
>>>>>> On 4/7/2016 10:52 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>> The testsuite before calls the model to change config as required. This
>>>>>> should just be changed to use admin endpoints. Isn't that all that's
>>>>>> required?
>>>>>>
>>>>>> I'm not sure.  The test-app displays a link to account management.
>>>>>> Presumably, one or more tests are relying on that particular link.
>>>>>> Plus,
>>>>>> since tests would then be relying on a different app (admin console),
>>>>>> there
>>>>>> would be cascading changes to the realm configuration and probably the
>>>>>> tests
>>>>>> themselves.
>>>>>>
>>>>>> See below.
>>>>>>
>>>>>>
>>>>>> On 7 April 2016 at 16:40, Bruno Oliveira <abstractj at redhat.com> wrote:
>>>>>>> Sorry about the lack of details. I'm looking more precisely at
>>>>>>> AccessTokenTest and migrating this method[1] which does not depends on
>>>>>>> OAuthClient.
>>>>>>>
>>>>>>> The "test-app" that I mentioned is this one[2].
>>>>>> Rather than refactoring OAuthClient and possibly any code that uses it,
>>>>>> I'm proposing to move forward and just deploy the little test-app when
>>>>>> the
>>>>>> server starts up.
>>>>>>
>>>>>> I'm worried about breaking these tests in unknown and possibly
>>>>>> undetectable ways.  Stian, if you've got time to look it all over then
>>>>>> we
>>>>>> can do something different, but I don't think Bruno and I know these
>>>>>> tests
>>>>>> well enough to change it safely.
>>>>>>
>>>>>> I'd rather make sure we can port the tests as-is without changes.  It
>>>>>> won't be hard to let the Keycloak server deploy the little servlet.
>>>>>> That
>>>>>> will at least let us move forward.  We can always change it later.
>>>>>>
>>>>>> Sound ok?
>>>>>
>>>>> Oki, but instead of deploying a WAR to Keycloak, something which is not
>>>>> supported, so may not work in the future, add a custom REST endpoint
>>>>> like
>>>>> what I did for the TimeOffset
>>>>>
>>>>>>> [1] -
>>>>>>>
>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/AccessTokenTest.java#L399
>>>>>>> [2] -
>>>>>>>
>>>>>>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/testrealm.json#L102
>>>>>>>
>>>>>>> On Thu, Apr 7, 2016 at 11:32 AM, Stian Thorgersen
>>>>>>> <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 7 April 2016 at 16:28, Bruno Oliveira <abstractj at redhat.com>
>>>>>>>> wrote:
>>>>>>>>> I will also try to take a look later today. I have more questions of
>>>>>>>>> course, actually I have to enable direct access grant for my
>>>>>>>>> "test-app".
>>>>>>>>
>>>>>>>> What's your "test-app"?
>>>>>>>>
>>>>>>>>> My question is: to not mess with other tests, should I just add a
>>>>>>>>> new
>>>>>>>>> client to testrealm.json or it's ok to do some changes as long as it
>>>>>>>>> does not break other tests?
>>>>>>>>
>>>>>>>> Depends on what your "test-app" is ;)
>>>>>>>>
>>>>>>>>> On Thu, Apr 7, 2016 at 7:56 AM, Stan Silvert <ssilvert at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>> On 4/7/2016 12:36 AM, Stian Thorgersen wrote:
>>>>>>>>>>
>>>>>>>>>> It can probably fairly easily be converted to not requiring
>>>>>>>>>> anything
>>>>>>>>>> to
>>>>>>>>>> be
>>>>>>>>>> deployed and instead just send to an invalid url. I can take a look
>>>>>>>>>> at
>>>>>>>>>> that
>>>>>>>>>> if you want?
>>>>>>>>>>
>>>>>>>>>> Yes, take a look and let me know what you think about that.  It
>>>>>>>>>> would
>>>>>>>>>> improve the design of it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6 April 2016 at 21:20, Stan Silvert <ssilvert at redhat.com> wrote:
>>>>>>>>>>> On 4/6/2016 9:26 AM, Stian Thorgersen wrote:
>>>>>>>>>>>
>>>>>>>>>>> The new one is just a simple method so I don't see the issue in
>>>>>>>>>>> merging
>>>>>>>>>>> the two (once the old is working that is)
>>>>>>>>>>>
>>>>>>>>>>> I over-simplified my question, which is why I was wanting to chat.
>>>>>>>>>>> But,
>>>>>>>>>>> I'm too far in the weeds to talk right now.
>>>>>>>>>>>
>>>>>>>>>>> This is getting a bit hairy because the old OAuthClient relies on
>>>>>>>>>>> the
>>>>>>>>>>> fact
>>>>>>>>>>> that there is a little application deployed with context
>>>>>>>>>>> http://localhost:8081/app.  So apparently, I've got to convert the
>>>>>>>>>>> undertow
>>>>>>>>>>> DeploymentInfo into a Shirkwrap WebArchive and let arquillian
>>>>>>>>>>> deploy
>>>>>>>>>>> the
>>>>>>>>>>> little app.
>>>>>>>>>>>
>>>>>>>>>>> But unless you guys can think of an easier solution I've got quite
>>>>>>>>>>> a
>>>>>>>>>>> bit
>>>>>>>>>>> of work to do before we discuss unification.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6 April 2016 at 15:09, Stan Silvert <ssilvert at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I've found a problem with the migrated OAuth client and I've been
>>>>>>>>>>>> trying
>>>>>>>>>>>> to work on that.
>>>>>>>>>>>>
>>>>>>>>>>>> The thing I wanted to discuss yesterday was about unification of
>>>>>>>>>>>> the
>>>>>>>>>>>> old
>>>>>>>>>>>> and new OAuth clients.  But that's a moot point as long as the
>>>>>>>>>>>> old
>>>>>>>>>>>> one
>>>>>>>>>>>> isn't
>>>>>>>>>>>> fully working with the new testsuite.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/6/2016 8:03 AM, Stian Thorgersen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Do you and Stan still want a chat? If so I can do it now
>>>>>>>>>>>>
>>>>>>>>>>>> On 6 Apr 2016 13:46, "Bruno Oliveira" <abstractj at redhat.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Great news!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Apr 6, 2016 at 6:24 AM, Stian Thorgersen
>>>>>>>>>>>>> <sthorger at redhat.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Bruno and Stan, thanks to Pedro we now have the ability to add
>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>> REST endpoints to Keycloak [1]. Also, thanks to Marko we can
>>>>>>>>>>>>>> add
>>>>>>>>>>>>>> already add
>>>>>>>>>>>>>> custom providers to the Arquillian testsuite. Once [2] is
>>>>>>>>>>>>>> merged
>>>>>>>>>>>>>> (in
>>>>>>>>>>>>>> an hour
>>>>>>>>>>>>>> or so) tests can easily set the time offset on the server. I
>>>>>>>>>>>>>> added a
>>>>>>>>>>>>>> temporary test that does exactly that [3].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There's a bit of clean-up to do with assert events and the
>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>> testsuite providers, but Marko can do that when he gets back
>>>>>>>>>>>>>> [4].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] https://issues.jboss.org/browse/KEYCLOAK-2262
>>>>>>>>>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-2590
>>>>>>>>>>>>>> [3] org.keycloak.testsuite.TempSetTimeOffsetTest
>>>>>>>>>>>>>> [4] https://issues.jboss.org/browse/KEYCLOAK-2755
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4 April 2016 at 14:30, Bruno Oliveira <abstractj at redhat.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Perfect and yes for Drone. That already helps with my n00bish
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> the test suite.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 9:26 AM, Stian Thorgersen
>>>>>>>>>>>>>>> <sthorger at redhat.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> KeycloakRule should be removed and replaced with extending
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> AbstractKeycloakTest. OAuthClient should be ported, but Drone
>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>> WebDriver
>>>>>>>>>>>>>>>> under the covers right? So it's just about changing how it's
>>>>>>>>>>>>>>>> injected.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4 April 2016 at 14:19, Bruno Oliveira
>>>>>>>>>>>>>>>> <abstractj at redhat.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> I know we have a meeting about it today, but I have a
>>>>>>>>>>>>>>>>> question —
>>>>>>>>>>>>>>>>> thinking about AccessTokenTest[1]. Should we keep the
>>>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>>>> structure as
>>>>>>>>>>>>>>>>> is and just replace WebDriver by Drone?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For example, from my poor understanding KeycloakRule,
>>>>>>>>>>>>>>>>> WebRule,
>>>>>>>>>>>>>>>>> OAuthClient should be migrated to the new test suite and the
>>>>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>>>>> refering
>>>>>>>>>>>>>>>>> to WebDriver ported to Drone[2].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Am I totally wrong?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1] -
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/AccessTokenTest.java#L96
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [2] - https://docs.jboss.org/author/display/ARQ/Drone
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 8:55 AM, Bruno Oliveira
>>>>>>>>>>>>>>>>> <abstractj at redhat.com> wrote:
>>>>>>>>>>>>>>>>>> Thank you Stan, will give it a try
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 8:46 AM, Stan Silvert
>>>>>>>>>>>>>>>>>> <ssilvert at redhat.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Bruno,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here is what I've done so far. Still have 9 migrated tests
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> this package that don't pass.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://github.com/ssilvert/keycloak/tree/migrate-admin/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/migrated/admin
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AbstractClientTest is where most of the adaptation to the
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> test
>>>>>>>>>>>>>>>>>>> suite happens.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Stan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 4/1/2016 11:04 AM, Bruno Oliveira wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That makes sense. I will check your commits and try to
>>>>>>>>>>>>>>>>>>> adapt to
>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks Stan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Apr 1, 2016 at 10:24 AM, Stan Silvert
>>>>>>>>>>>>>>>>>>> <ssilvert at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>> Having never done this before, we don't have any
>>>>>>>>>>>>>>>>>>>> guidelines.
>>>>>>>>>>>>>>>>>>>> But
>>>>>>>>>>>>>>>>>>>> I can tell you how I am approaching this at the moment.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't want to touch the actual test code if possible.
>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>> reason is that there is no way I could fully understand
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> intent of the
>>>>>>>>>>>>>>>>>>>> original author.  Changes to the test code could yield
>>>>>>>>>>>>>>>>>>>> false
>>>>>>>>>>>>>>>>>>>> positives and
>>>>>>>>>>>>>>>>>>>> we would end up with code that doesn't actually test what
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> was intended to
>>>>>>>>>>>>>>>>>>>> test.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So I copy over the original test class and get rid of the
>>>>>>>>>>>>>>>>>>>> annotations that pertain to the old environment.   Then I
>>>>>>>>>>>>>>>>>>>> write adapter code
>>>>>>>>>>>>>>>>>>>> that lets the test code remain unchanged while calling
>>>>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>>>> the new
>>>>>>>>>>>>>>>>>>>> environment.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Of course, there is risk in that approach as well, but it
>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>> less than if I tried to modify the original test methods.
>>>>>>>>>>>>>>>>>>>> And
>>>>>>>>>>>>>>>>>>>> it seems to
>>>>>>>>>>>>>>>>>>>> be working well as about 75% of my tests are passing
>>>>>>>>>>>>>>>>>>>> unchanged
>>>>>>>>>>>>>>>>>>>> with only a
>>>>>>>>>>>>>>>>>>>> minimal bit of adapter code written so far.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For this reason, I rejected extending AbstractAuthTest in
>>>>>>>>>>>>>>>>>>>> favor
>>>>>>>>>>>>>>>>>>>> of my own abstract class that just extends
>>>>>>>>>>>>>>>>>>>> AbstractKeycloakTest.   That new
>>>>>>>>>>>>>>>>>>>> abstract class is where the adapter code lives.  I also
>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> concerns about
>>>>>>>>>>>>>>>>>>>> duplication of effort so hopefully at some point I can
>>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>>>>>> generic code
>>>>>>>>>>>>>>>>>>>> that applies to all the migrated tests instead of just
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> ones I'm working
>>>>>>>>>>>>>>>>>>>> on.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But by then, we might be all done anyway...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 4/1/2016 6:23 AM, Bruno Oliveira wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Good morning, I have a question to prevent duplicated
>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>> Taking as an example AccessTokenTest[1].
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In order to execute the tests we have an user
>>>>>>>>>>>>>>>>>>>> "no-permissions"
>>>>>>>>>>>>>>>>>>>> with the role "user". Add an user is easy if I extend
>>>>>>>>>>>>>>>>>>>> AbstractAuthTest[2],
>>>>>>>>>>>>>>>>>>>> at the same time we don't have any method to assign the
>>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>>> "user".
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To follow the correct guidelines. Should I extend
>>>>>>>>>>>>>>>>>>>> AbstractAuthTest and add the proper method to assign
>>>>>>>>>>>>>>>>>>>> roles
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>>>>>>> class? Or this is definitely wrong?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [1] -
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/AccessTokenTest.java#L96
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [2] -
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/7c64ab228b7c95646c54caa4e1562512d18bd4e2/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/AbstractAuthTest.java#L43-L43
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 3:26 PM, Stian Thorgersen
>>>>>>>>>>>>>>>>>>>> <sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>>> We need to co-ordinate who migrate which tests. I'm not
>>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>> available this week, but will be checking email at least
>>>>>>>>>>>>>>>>>>>>> once
>>>>>>>>>>>>>>>>>>>>> a day. I will
>>>>>>>>>>>>>>>>>>>>> be fully operational next week.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Prerequisites to migrating tests are:
>>>>>>>>>>>>>>>>>>>>> * Port assert events (there's a PR from Marko on this
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>> to review and merge it)
>>>>>>>>>>>>>>>>>>>>> * Ability to set time offset through admin endpoints
>>>>>>>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>>>>>>>> required for expirations or other time sensitive tests)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Once those are done we can start migrating tests. To
>>>>>>>>>>>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>>>>>>> multiple folks porting the same tests, here's your
>>>>>>>>>>>>>>>>>>>>> initial
>>>>>>>>>>>>>>>>>>>>> list to port
>>>>>>>>>>>>>>>>>>>>> (packages in
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/testsuite/integration/src/test/java/org/keycloak/testsuite):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> * Stan - admin (these may be duplicates in the new admin
>>>>>>>>>>>>>>>>>>>>> endpoints tests), actions
>>>>>>>>>>>>>>>>>>>>> * Bruno - oauth, forms
>>>>>>>>>>>>>>>>>>>>> * Bolek - account
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That's right, we're so behind with tests that even the
>>>>>>>>>>>>>>>>>>>>> engineering manager has to start coding.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Let's use this thread as a place to discuss progress and
>>>>>>>>>>>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>>>>>> around migrating the tests.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -
>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> abstractj
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> abstractj
>>>>>>
>>>>>>
>>>>
>
>

More information about the keycloak-dev mailing list