Progress

Exams ended for me last tuesday, so I've had lots of time to code on xTest. I've done three major things the last couple of days:

• Upgrade looks to use Dolphins fade-in selection instead of checkboxes
  
• Make the CppUnit plugin run through an executable + parse xml back in
  
• Initial Check support
  

Couple of shots of the current state:

QTestLib runner prototype

An initial QTestlib runner is finished but still lacks severely:

• Real slow
  
• Feels KDE3'ish
  
• Static test registration
  

Slowness is the result of running a QTest executable for each of the test commands separately, instead of just once for each testcase. This'll obviously get fixed as soon as possible. Just to give you an idea: Kdevelop4's suite runs in about 3 seconds under CTest. The current plug in requires 30-ish ...

Second major flaw is looks. Especially the icons and combo box-tree are not up to standards. I'll probably use the test-status icons for selection as well (in front of the tests).

The actual test executable locations are still being read statically from XML. The location of this XML is, compiled in the hard way :) I'll sort this out by using the project configuration, the build API for test location and probably DUChain for suite structure detection.

To try it out yourself:

• Checkout kdevelop and kdevplatform from trunk
  
• De-comment the xtest plugin in kdevelop/plugins/CMakeLists.txt
  
• Adapt KDEV_HOME in kdevelop/plugins/xtest/xtestplugin.cpp:35
  
• Adapt the dir attribute of <root> in kdevelop/plugins/xtest/kdevtests.xml
  
• Build and install
  
• Fire up Kdevelop4 and add the xTest plugin through view->Add Tool View
  

XmlPatterns 101

Just this month Qt4.4 was released. Amongst the hot new stuff is QtXmlPatterns, which packs a C++ XQuery API. XQuery is a full blown typed XML query language based on XPath combined with so called FLOWR expressions [for-let-where-orderby-return]. While it's main goal is XML transformation one can abuse it as an ultra concise parser. Let's see a small example.

<?xml version="1.0" encoding="ISO-8859-1"?>
<root>
   <suite name="suite1" dir="/a/b">
   <case name="test1" exe="t.sh">
       <command name="cmd11" />
       <command name="cmd12" />
   </case>
   <case name="test2" exe="t2.sh">
       <command name="cmd21" />
   </case>
   </suite>
</root>

Say we want to extract dir, exe and name for each command in the listing above. This can be done in just four lines of XQuery, quite economic compared to your average dom-traversal code.

    QXmlQuery query;
   query.setQuery(
       "for $suite in doc(\"test.xml\")//suite\n"
       "for $case  in $suite/case\n"
       "for $cmd   in $case/command\n"
       "return concat($suite/@dir, '/', $case/@exe, ' ', $cmd/@name)\n");
   QStringList cmds;
   query.evaluateTo(&cmds);

At this point the 'cmds' QStringList contains:

("/a/b/t.sh cmd11", "/a/b/t.sh cmd12", "/a/b/t2.sh cmd21")

WASDeTT 2008

The other day I got confirmation on participation in WASDeTT. A Cyprus-based workshop on tool-building cohosted with ECOOP08 . Exciting to say the least! I'm really looking forward to this, especially since it'll be totally funded by my uni - subscription cost partly recuperated :)

I'll be presenting TestQ a prototype tool built as undergraduate project under the guidance of members from the LORE research group. Maybe I'll pick up some ingenious ideas for the GSOC [while enjoying the superb weather]

Acunote

Yesterday apaku suggested to use acunote.com, a project management and planning tool which streamlines progress communication. Next to extensive milestone scheduling it has direct integration with subversion. This allows for interesting features such as source annotations based on the commit diffs. It's implemented as a webservice in full 2.0 glory. All of this drenched in Agile Scrum terminology, yummy!

Apparently the authors are OSS enthusiasts themselves, as a result this service is gratuite for GSOC projects (and OSS in general). Though they haven't gone as far as opening it all up, yet. Evgeniy Ivanov is using it as well for his Kdevelop4 DVCS integration GSOC, which might have something to do with their git support :)

Milestone 2

I plugged QxRunner into Kdevelop4, as planned. While still far from fully functional it's nice to see some progress anyway. The screenshot below shows a small CppUnit suite. It's not dynamic at all though, just compiled in the hard way. I'm, however, quite happy with how it turned out visually. Might have to remove the result view (widget in the lower left corner) with something more flexible though, maybe based on the filesystem-plugin scroll thingy.

g++ linkage on 64 bit

/usr/bin/ld: /home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a(testrunner.o):
relocation R_X86_64_32S against `vtable for QxCppUnit::TestRunner' can not be
used when making a shared object; recompile with -fPIC
/home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a: could not read symbols:
Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/kdevxtest.so] Error 1

A cookie for those that decipher this g++ gibberish. And yes, "-fPIC" was present. Apaku, who's mentoring me, told me this happens when you try to link a static library into a shared one. Apparently this is not supported in the 64bit gcc implementation and hence forbidden in KDE. Funnily enough the same construct runs without a hitch on x86.

Related to this I learned about gcc's DSO visibility concept. Marking symbols as visible in a shared library is typically done with an export macro. In the original QxRunner this macro was activated externally by the buildsystem, which I overlooked when converting to CMake. This resulted in totally mangled shared libs ... not good.