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

[Marek Posolda]

On 10.2.2014 22:02, Bill Burke wrote:
> I still think there is a bit of model work to be done.  This is why I've
> turned off the picketlink and mongo builds as it is a pain to keep them
> in sync while we're developing new features.
The disadvantage of current approach with all unit tests in "services" 
module is that you need to have dependencies with scope "test" declared 
in services/pom.xml for all model implementations, which means that 
there are both hibernate, picketlink and mongo dependencies. And if you 
want to disable some model, you need to disable line in pom.xml but also 
these test dependencies in services/pom.xml
>
> But, the idea was that Model classes are as close to the data model as
> possible with as little business logic as possible.  Manager classes are
> business logic, and the Resource/Service classes are the JAX-RS layer.
> We need to move logic to Manager layer and create a better API at the
> Manager level.  Then move the Manager code to another module (model-api?).
>
> We used to run mongo, picketlink, and JPA as you describe (you
> implemented it).
Ok, so I am seeing 2 possible ways how to proceed:
1) Create new module as you described (not sure about model-api as we 
already have "model/api" . How about "model-managers" or "model-logic" 
?) and move some manager classes like RealmManager, ApplicationManager, 
OAuthClientManager etc. to this. This module will have dependency just 
on "core" and "model/api" . I will keep rest of manager classes, which 
are not used to model logic but mainly for jax-rs handling logic (like 
TokenManager, SocialRequestManager etc) in services module. Then I will 
move some model related tests from "services" module to this new module. 
All concrete model implementations like "model/jpa" , 
"model/picketltink" or "model/mongo" will have test-scoped dependency on 
this model-logic module and will run all unit tests during it's own build.

In "services" module, I will keep just unit tests not related to model 
logic (like EmailSenderTest for instance)


2) Keep unit tests in "services" module and just add some profiles like 
I mentioned. Especially running -Dkeycloak.model=all will run unit tests 
with all available model implementations. This will leverage junit 
parameterized approach and model related tests will be changed to be 
subclass of AbstractKeycloakTest (This is what I already have in my 
working copy)

I prefer 1 but it's more work and more required changes of current 
project structure. wdyt?

Marek
>
> On 2/10/2014 3:45 PM, Marek Posolda wrote:
>> Hi,
>>
>> For improving testability, it would be nice if it's possible to execute
>> unit tests with all available model implementations.
>>
>> It seems that for testability of various model implementations, it may
>> be good to move majority of unit test classes (like AdapterTest,
>> ImportTest etc) from module "services" into "model/api" and then each
>> model implementation will run all unit tests for particular model during
>> it's own build. So building of module "model/jpa" will run all unit
>> tests with JPA model and similarly building of "model/mongo" will run
>> same set of tests for mongo module. This means that unit tests for all
>> enabled models will be automatically executed during Keycloak build,
>> which means that various model implementations won't be out of sync.
>>
>> This would mean that some util classes used in unit tests will be moved
>> from services to model/api as well because unit tests need them (For
>> example RealmManager, ApplicationManager etc.)
>>
>> Another possibility is to keep unit tests in "services" module and just
>> add some dedicated profile for running tests with Mongo. So for example
>> -Dkeycloak.model=mongo will run unit tests with Mongo model and
>> -Dkeycloak.model=all will run unit tests with all available model
>> implementations (so currently jpa and mongo).
>>
>> What do you think?
>>
>> Thanks,
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>