Test plugin and library

[Aleix Pol]

On Tue, Mar 15, 2011 at 9:08 PM, Miha Čančula <miha at noughmad.eu> wrote:

> Hello!
>
> I've moved the Veritas library and the QTest plugin from svn to git
> playground. After getting to know the code, the first thing I did was change
> the tree view's look to match the Project toolview. As you can see in the
> attaches screenshots,  both use a QTreeView with the same indentation and
> decorations. I also introduced checkboxes, modeled after other selectable
> treeviews in KDE, such as the one for selecting your collection folders in
> Amarok. I removed the hover-icon method of selecting and deselecting tests
> to run in favor of checkboxes. I might not be a usability expert, but I do
> like consistency, so I tried to make the UI as similar to existing ones
> (Projects, Snippets, Classes) that use QTreeViews. The plugin itself works
> as expected (no significant changes to QTestLib while it was unmaintained),
> so I haven't touched that yet.
>
> My next plan is to remove the remaining hover-icons, and provide a RMB-menu
> instead. Another thing I'd like to do is remove the project selection
> dropdown, and just list all projects in the tree. This not only matches the
> Projects view, but reduces the number of clicks needed to start using the
> plugin. But before I proceed to mindlessly destroy the hard work of others,
> I'd like to know what else would have to be done to make the plugin
> KDevelop-worthy. Aleix (I suppose he read this list), you posted the GSoC
> idea, what exactly did you have in mind? And how should the the plugin (both
> the test-tree and the result-view) look to best match KDevPlatform's
> standards?
>
> And the last thing, I would very much like to work on KDevelop/KDevPlatform
> as part of the summer of code. I know I haven't made any contributions to
> KDev* yet, but I am following its development and I'm somewhat familiar with
> the code (at least the architecture). My first idea this year was this test
> runner, but as one backend is already working, would it be worth a slot or
> should I try something else? A possibility would be adding support for other
> test frameworks, like CppUnit and Boost, but I don't know of any KDE program
> that would use those.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
What I would like to see in a proposal referring to the
Unit Testing integration in KDevelop GSoC is a proposal where the student
says he's going to fix whatever it's wrong now and make it usable and gives
his thoughts on how does he want it to be integrated in KDevelop. I don't
think it should be me who says what the proposal should be about.

Awesome QtTest + cmake integration by the end of the GSoC is a must, but
it's not the only thing. KDevelop is about integrating tools, I'd like to
see what is the student's idea of how should unit tests be run while
developing and how should it be integrated. For instance, what if a test is
crashing, how do we debug it? Can we just run the tests that are relevant to
the file we're editing? How can we find regressions using veritas?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110316/62a243ee/attachment.html>