Designing for testability

[M Breugelmans]

On Mon, Sep 15, 2008 at 11:06 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> Hi,
>
> while writing the tests for the new sessioncontroller I've reached a
> dead end. Basically I currently can't test wether the session provides
> the right data area for a plugin because there's no easy way to obtain
> an IPlugin and have plugincontroller know about the plugininfo for that
> plugin. The reason for this is that Core and the controller's are
> coupled pretty tightly, which means I can't just replace the
> plugincontroller with my own that just has 1 IPlugin subclass hardcoded.
>
> Now the question is how to best achieve that decoupling in a way that
> also usable for testing plugins. Basically I'd like to be able to
> replace any or all of the controller's when creating a Core object.
> Obviously those special classes need to be subclasses of the existing
> controller's overriding the important bits of them.
>
> One possibility I can think of currently is providing setters for the
> controller's and having CorePrivate check if any of the controller's is
> already set to a valid value before creating a new instance of it.
>

A bunch of setters seem like a decent option, it's not decoupling
though ;) But then the whole idea behind the core architecture is to
have a small tightly coupled kernel. It probably doesn't make sense to
try and change that.

I think Core::initialize will have to be made non-static. Maybe have a
Core::create static method instead. This way certain controllers could
be re-initialized. Very useful to start off clean in each test command
... the last thing you want are buggy interacting tests.


Manuel