[keycloak-dev] Running unit tests with different model implementations

[Marek Posolda]

I've sent PR https://github.com/keycloak/keycloak/pull/199 for mongo 
model and for changes in unit tests as mentioned previously (introducing 
model/tests module and moving unit tests from "services" module)

I would be happy if you can merge it just to avoid later conflicts 
during rebasing with master. Feel free to disable mongo model again if 
you need to add more features into model API and don't want to edit files.

It seems that from the changes/refactoring you mentioned below there 
will be changes in model just for UUID stuff. If you not already started 
on it, I can look at it and add support for it into both jpa and mongo 
models (from last mail on this, you want to use UUID generated from 
IdGenerator like "1-4564897" which should ensure that there won't never 
be any collision, right?)

It seems that other user related features won't require much changes on 
model if I am not wrong? Unless some realm configuration options, which 
should be quite easy to add into both model implementations.

Marek

On 11.2.2014 17:33, Stian Thorgersen wrote:
> Sounds good. Getting Mongo in now is a priority for us, but it doesn't have to be perfect now.
>
> With regards to refactoring changes proposed they all sound great, but I agree with Bill. Let's do a few more rounds to get some more "core" features in. Then let's do refactoring, testing, etc..
>
> At this point there's no immediate refactoring I can think of, except for swapping from DB generated IDs to UUIDs + the changes to users I proposed:
>
> * Login with username or email
> * Use id in token#sub
> * Remove recover username
> * Let users change their username (probably an option on the realm to disable?)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 11 February, 2014 3:50:03 PM
>> Subject: Re: [keycloak-dev] Running unit tests with different model	implementations
>>
>> Sounds good.
>>
>> On 2/11/2014 10:45 AM, Marek Posolda wrote:
>>> Thanks for the clarification, thing is that we may need mongo model in
>>> alpha 2 too because of liveoak.
>>>
>>> So for now I did not made any big refactoring and movement of existing
>>> manager classes. I just introduced new module "model/tests" and moved
>>> just existing model related unit tests (basically everything except
>>> EmailSenderTest) from "services" module to this one. Then I configured
>>> model/jpa and model/mongo modules to use tests from this one. So
>>> currently all these model unit tests are always executed during build of
>>> particular model implementation (ie. building model/jpa runs all tests
>>> with "jpa" model implementation and building model/mongo runs all tests
>>> with "mongo" model implementation).
>>>
>>> So only thing moved to different location are those unit tests classes.
>>> Is this acceptable change for Alpha 2?
>>>
>>> With this change, if you decide to enable/disable some model
>>> implementation, you will need just comment/uncomment one line in
>>> model/pom.xml and that's it. Side-effect of this is that many
>>> test-scoped dependencies from "services" module are not needed anymore
>>> (especially hibernate and H2, which were needed for "jpa" model)
>>>
>>> Testsuite is executed just with JPA model by default, there is separate
>>> profile for running it with mongo, which is used only if you add
>>> -Dkeycloak.model=mongo .
>>>
>>> Hope to send PR with mongo model later today or early tomorrow with this
>>> change introduced.
>>>
>>> Thanks,
>>> Marek
>>>
>>> On 10.2.2014 23:50, Bill Burke wrote:
>>>>
>>>> On 2/10/2014 4:51 PM, Marek Posolda wrote:
>>>>> I prefer 1 but it's more work and more required changes of current
>>>>> project structure. wdyt?
>>>>>
>>>> I agree. I thought that was the plan even before this email.  That we
>>>> needed restructuring of the codebase to separate JAX-RS code from
>>>> business logic, from model logic.  That we needed more comprehensive
>>>> testing.
>>>>
>>>> Minimally, to do this work we have to wait until after Alpha 2 (end of
>>>> this week).  But my preference is that there is no refactoring work at
>>>> all until we're done with core feature implementations or unless a
>>>> feature needs the refactoring.  I just don't want merge conflicts
>>>> distracting people from feature work. Stan took awhile to merge his
>>>> keycloak subsystem because our code was a moving target.  I've had
>>>> delays before because of merge conflicts as well.
>>>>
>>>> My thought is that we will have a few more Alphas every 2-3 weeks.
>>>> Going into Beta will mean that our major features have been
>>>> implemented and we'll then start focusing on test coverage,
>>>> refactoring, cleaning up code, documentation, and polishing the project.
>>>>
>>>> But, Stian can be the tie-breaker here if he wants this refactoring to
>>>> happen sooner rather than later.  I'll go with what he wants.
>>>>
>>>>
>>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>