Testing KTp

[George Kiagiadakis]

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.