Testing KTp

[David Edmundson]

On Wed, Sep 19, 2012 at 4:09 PM, George Kiagiadakis
<kiagiadakis.george at gmail.com> wrote:
> On Wed, Sep 19, 2012 at 5:13 PM, David Edmundson
> <david at davidedmundson.co.uk> wrote:
>> On Wed, Sep 19, 2012 at 1:54 PM, Daniele E. Domenichelli
>> <daniele.domenichelli at gmail.com> wrote:
>>> Agreed, this is rubbish. A checklist could be useful if used properly...
>>> This is my proposal:
>>>
>>> - We keep the checklist on the wiki.
>>
>> Ok, I'll start this, though I would like some help.
>> http://community.kde.org/Real-Time_Communication_and_Collaboration/ReleaseTesting#Release_Testing_for_X.Y-rc1
>>
>> It's deliberately quite vague and simple.
>>
>> If we start writing proper test specs with detailed "ensure X happens,
>> and ensure Y is ... " no-one will write them, and no-one will bother
>> to run it.
>>
>> There's tonnes more to add to that list, so get to it :)
>>
>
> And imho, we should gradually turn most of these tasks to automatic
> unit tests. It is not that hard and will save us a lot of trouble.
>
> And here comes into play telepathy-parrot, the echo bot - unit testing
> framework that I am writing, which I started writing exactly for this
> purpose ;) tp-parrot is meant to automate the process of starting
> temporary telepathy sessions & optionally a temporary prosody
> instance, setting up accounts, running clients and setting up certain
> environment conditions for those clients (ex, starting channels). This
> can be useful for manual testing of handlers (call ui, text ui), but
> it can also become useful for automatic testing of several components.
> What needs to be done, however, is to turn components into (static)
> libraries so that they can be accessed from QtTest-based unit tests.
> QtTest can do wonders with UIs, it can simulate mouse clicks, key
> presses, etc, but it needs access to the widget pointers where the
> events should go. Ok, this may not be able to test everything, but
> still many things can be tested that way. In the particular case of
> ktp-send-file, for example, I believe it should be possible to
> automate it fully.

That all sounds super cool, that said I don't want to fall into the
trap of saying "we'll automate all of this", then end up doing nothing
at all.

Writing a wiki page and opening some apps is still a simple solid
approach. If stuff gets automated, we can remove it from this list -
though a human at least opening each component before a release is
still a good thing to do.

Dave

> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy