3:51 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>