Activating Documents with a range is broken since d77c94c1402916f8f00b02104f71187330548ecd

[Andreas Pakulat]

Hi,

On Thu, Dec 13, 2012 at 12:10 PM, Milian Wolff <mail at milianw.de> wrote:
> On Wednesday 12 December 2012 23:28:35 Andreas Pakulat wrote:
>> I think the best way at the moment to test such changes in the core is
>> putting them into master to get as many testers as possible. The only
>> viable alternatives i see are to get all active developers and a
>> couple of users to use a staging branch locally where they merge all
>> currently-active feature branches and report back any issues they find
>> (and which branches they merged locally). Or alternatively to have
>> unit-tests and ui tests for these things and make it dead-easy to add
>> new ones. Neither of the two seem to be possible in the short-term.
>
> True. We should think about maybe offering a GSOC slot next year to get some
> Squish testing setup for KDevelop, such that we are better able to test our UI
> parts. What do you think - would you maybe have time to mentor such a project?

Hrm, I see what you're trying to do here ;) My experience with GSoC so
far was that it was quite involved for me and I doubt you'll find
someone experienced with Squish that would be willing to write a
testframework as GSoC.

This also needs quite some preparation to be successful too, i.e.
there needs to be a plan on what exactly should be tested. At work
we've started with some 'user stories' of absolutely crucial
functionality that must be guaranteed to work and formed a basic
framework from that which allows us to add new tests relatively easily
(compared to the complexity of the required setup).

Someone has to write these stories and come up with what needs to be
checked at each step, then figure out how to do this in Squish and
then factor out the common stuff and come up with a test-framework
that makes it easy to write future tests by doing something like:

startKDevelop(projectDescription)
openProjectConfig(projectName)
verifyPageVisible("CMake")
verifySelectedCMakeBuildDir("/path")
switchBuildDir("/otherpath")
verifySelectedCMakeBuildDir("/otherpath")
shutdownKDevelop()

And simply run this and have it succeed (or fail if there's a bug).
Just and example.

>> So I'd say, lets try to hammer out any further possible regressions,
>> maybe re-evaluate the commits by putting them into reviewboard or just
>> reviewing them locally to see what could possibly be affected by them
>> and then test that out more. At least its still rather easy to bisect
>> these and find the culprit for a bug if its related to the
>> document/view changes and thus get a clue where the bug could hide.
>
> OK, lets do it this way then. I hope to have some more time on the weekend
> again and will try to look into this then.

I was planning to see wether I can find a few hours to look at the
lazy initialization again since its quite an interesting puzzle. (I
like to puzzle)

Andreas