Unit testing (once again)

[Miha Čančula]

2012/2/8 Miha Čančula <miha at noughmad.eu>

> 2012/2/7 Aleix Pol <aleixpol at kde.org>
>
>> **
>> Hi Miha!
>>
>> First of all, I'm happy you're committed to taking over the Unit Test
>> framework, it's something we really need! :)
>>
>>
>>
>> In my opinion it shouldn't be linked to the project manager, but a
>> different interface that the project manager might implement. (think of
>> python or ruby projects). What I'd do is something like we do in VCS, where
>> you identify a provider for the project who reports the relevant cases.
>>
> Ok, I'll take a longer look at that. But I agree it should be something
> like that.
>
>>
>>
>> A provider can be ctest for cmake (it can be implemented by the project
>> itself) but you can have different ones for qmake or python projects. A
>> test entry would be some executable+arguments pair to be run.
>>
> That's what I had in mind.
>
> @henry: Yes, I'm trying to do just that, the possibility of different test
> providers with the same UI.
>
>>
>>
>> Do you guys think it makes sense? :P
>>
>> Aleix
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>
>>
> One more question: Apart from a plugin interface, it would be good to have
a concrete Test class that would hold the tree structure, the displayed
name and executable with arguments. A specialized Job class would be nice
as well. I'd put both the ToolView and the generators in separate plugins,
so nothing else is needed in KDevPlatform itself. These don't belong to
/interfaces, but at the same time I don't think a separate library for two
classes is worth it. Where can I put these classes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120208/e635745e/attachment.html>