performance optimization breaks tests

[Andreas Pakulat]

Hi,

On Sun, Nov 4, 2012 at 3:16 PM, Milian Wolff <mail at milianw.de> wrote:
> On Sunday 04 November 2012 10:39:16 Andreas Pakulat wrote:
>> Hi,
>>
>> the recent optimization of using IndexedString in the project API
>> breaks ui-tests. Or rather it makes it necessary to have anything that
>> uses TestProject also create the complete kdevplatform shell. This is
>> not good, tests should be easy to setup, extend, maintain and run and
>> requiring a Core for a simple test-app is a major downside IMHO.
>
> I agree, but if the gain for the full application by far exceeds the gain,
> then I think we have no other option.

Actually I partially disagree. If its becoming more cumbersome to
write unit-tests, then you actually damage the main application since
it'll not get any new tests by people not interested in writing so
complicated unit-tests.

> Though, which "recent" optimization are you talking about exactly?
>
> 0df2338560cc6f0ca239a31e561c76d5789d3443 <-- that was recent but is not
> actually introducing anything new.

It does introduce new behaviour (not new API though), in particular it
requires being able to access the repository when setting a url.

I also just noticed that TestProject class was also changed in an
incompatible way in b00eca9d, which also requires a core-object. That
should actually also cause a crash but I don't know why I don't hit
this at the moment. So maybe thats actually the one causing the
problem for me and not so much the dependency of the project model
onto the itemrepository.

>> I noticed this regression with the ui-testapp I've written to test
>> ui-changes in the kcm for project-managers/custom-buildsystem. It
>> crashes now because suddenly an itemrepository is required for a
>> TestProject and this requires Core etc. to be setup.
>>
>> Any ideas how to fix that (without re-introducing the memory overhead
>> again)?
>
> Yes, setup the test core, it's a matter of a few lines of code. Then for speed
> you might want to disable all plugins, see TestPluginController and
> bf3c04a9ff7387e8653ecbd7bf181582b8bd7eef for how to do that. In the future, I
> want to enable this by default, i.e.: do not load any plugins in the tests.
> Then each test will have to manually specify which one it wants to load - if
> it needs any at all.

See, tons of things that are needed and can be done incorrectly
raising the entry level to creating unit-tests.

TestProject was actually never meant to be "working like the real
one", thats the whole point of mocks, the user (in the test) can
define the behaviour and even make it work incorrectly. I guess I'll
just drop usage of TestProject and write a new IProject subclass which
I can use in my app :(

Andreas