[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: Unit testing (once again)
From: henry miller <hank () millerfarm ! com>
Date: 2012-02-07 20:12:13
Message-ID: 8cbd48e4-5324-4b4c-9b56-e3dd2b5c5647 () email ! android ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Makes sense. Just make sure that my cmake project that doesn't use ctest (don't ask) \
can implement a custom solution for our setup if I ever get around to writing it.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Aleix Pol <aleixpol@kde.org> wrote:
On Tuesday 07 February 2012 18:00:36 Miha Čančula wrote:
Hello!
I had a grand idea of finishing and integrating the unit testing plugin in KDevelop \
over the last summer. Unfortunately, I ended up working on something else all summer, \
so the testing idea got forgotten. However, now I have some free time on my hands \
again, and I started refactoring and partially rewriting the whole plugin.
Compared to the existing implementation, it now has a cleaner \
interface-implementation separation, a tree view similar to the one in the project \
view, and is smaller. I made a scratch repo for it at \
http://quickgit.kde.org/index.php?p=scratch%2Fmihac%2Fkdev-unit-test.git&a=summary. \
So far I mostly moved code around and only written a little of my own, but now I am \
at the point where new code would have to be written, and I turn to you for \
suggestions. Basically, I see three options.
1. Keep the whole thing in a plugin. This means a separate view for the test tree and \
their output, and it would only work with CTest. It is basically what's there now. \
For KDE/C++ it is enough, but other languages have their own test frameworks.
2. Separate the general view code in one plugin, and the CTest code in another, with \
a single new interface in Kdevplatform. The view plugin basically loads the test \
runner plugin for each project. Not much changes, except the possibility of using \
other test frameworks. The interface doesn't have to be used from anywhere within \
KDevelop, only for plugin loading and dependency, but uses could be added later.
3. Integrate it all the way into the Project framework, adding a new ITestController \
interface in projects. A possibility is also a custom ProjectBaseItem subclass for \
showing the tests inside the project view.
Personally, I am leaning towards 2, but it requires (minor) changes to Kdevplatform, \
so I better ask first. Otherwise, I'll go with 1 as it covers most KDE projects. The \
third option is there only if you feel the need to have unit testing integrated with \
other services, like automatic running of all tests before committing, and showing \
tests on the project tree. It also means more work, so I wouldn't do it without at \
least some help from the core team.
If I get an "OK" for going the second route, I'll post a review request where it \
would be easier to discuss the new interfaces.
I am not a regular KDevelop developer, but I use it every day, so I thought this \
might be a good way of becoming one.
Thank you,
Miha
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.
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.
Do you guys think it makes sense? :P
Aleix
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" \
content="1" /><style type="text/css"> p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'Ubuntu'; font-size:9pt; font-weight:400; \
font-style:normal;"><br> <br>
Makes sense. Just make sure that my cmake project that doesn't use ctest \
(don't ask) can implement a custom solution for our setup if I ever get around to \
writing it.<br> <br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div \
class="gmail_quote">Aleix Pol <aleixpol@kde.org> wrote:<blockquote \
class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, \
204, 204); padding-left: 1ex;">
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;">On Tuesday 07 February 2012 \
18:00:36 Miha Čančula wrote:<br /></p> <p style=" margin-top:12px; \
margin-bottom:12px; margin-left:40px; margin-right:40px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;">Hello!<br /></p> <p style=" margin-top:12px; \
margin-bottom:12px; margin-left:40px; margin-right:40px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;">I had a grand idea of finishing and integrating \
the unit testing plugin in KDevelop over the last summer. Unfortunately, I ended up \
working on something else all summer, so the testing idea got forgotten. However, now \
I have some free time on my hands again, and I started refactoring and partially \
rewriting the whole plugin. </p> <p style=" margin-top:12px; margin-bottom:12px; \
margin-left:40px; margin-right:40px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;">Compared to the existing implementation, it now has a cleaner \
interface-implementation separation, a tree view similar to the one in the project \
view, and is smaller. I made a scratch repo for it at <a \
href="http://quickgit.kde.org/index.php?p=scratch%2Fmihac%2Fkdev-unit-test.git&a=summary"><span \
style=" text-decoration: underline; \
color:#0057ae;">http://quickgit.kde.org/index.php?p=scratch%2Fmihac%2Fkdev-unit-test.git&a=summary</span></a>. \
So far I mostly moved code around and only written a little of my own, but now I am \
at the point where new code would have to be written, and I turn to you for \
suggestions. Basically, I see three options. </p> <p style=" margin-top:12px; \
margin-bottom:12px; margin-left:40px; margin-right:40px; -qt-block-indent:0; \
text-indent:0px; -qt-user-state:0;">1. Keep the whole thing in a plugin. This means a \
separate view for the test tree and their output, and it would only work with CTest. \
It is basically what's there now. For KDE/C++ it is enough, but other languages have \
their own test frameworks. <br /></p> <p style=" margin-top:12px; margin-bottom:12px; \
margin-left:40px; margin-right:40px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;">2. Separate the general view code in one plugin, and the CTest \
code in another, with a single new interface in Kdevplatform. The view plugin \
basically loads the test runner plugin for each project. Not much changes, except the \
possibility of using other test frameworks. The interface doesn't have to be used \
from anywhere within KDevelop, only for plugin loading and dependency, but uses could \
be added later. <br /></p> <p style=" margin-top:12px; margin-bottom:12px; \
margin-left:40px; margin-right:40px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;">3. Integrate it all the way into the Project framework, adding a \
new ITestController interface in projects. A possibility is also a custom \
ProjectBaseItem subclass for showing the tests inside the project view. </p> <p \
style=" margin-top:12px; margin-bottom:12px; margin-left:40px; margin-right:40px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Personally, I am leaning \
towards 2, but it requires (minor) changes to Kdevplatform, so I better ask first. \
Otherwise, I'll go with 1 as it covers most KDE projects. The third option is there \
only if you feel the need to have unit testing integrated with other services, like \
automatic running of all tests before committing, and showing tests on the project \
tree. It also means more work, so I wouldn't do it without at least some help from \
the core team. <br /></p> <p style=" margin-top:12px; margin-bottom:12px; \
margin-left:40px; margin-right:40px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;">If I get an "OK" for going the second route, I'll post a \
review request where it would be easier to discuss the new interfaces. <br /></p> <p \
style=" margin-top:12px; margin-bottom:12px; margin-left:40px; margin-right:40px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I am not a regular KDevelop \
developer, but I use it every day, so I thought this might be a good way of becoming \
one.</p> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Thank you, \
<br />Miha<br /></p> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Hi \
Miha!</p> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">First of \
all, I'm happy you're committed to taking over the Unit Test framework, it's \
something we really need! :)</p> <p style="-qt-paragraph-type:empty; margin-top:0px; \
margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; \
text-indent:0px; "> </p> <p style=" margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;">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.</p> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p> <p style=" \
margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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.</p> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p> \
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Do you guys think it makes \
sense? :P</p> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;">Aleix</p></blockquote></div></body></html>
--
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic