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.

QxRunner test suite

While coding hasn't officialy started yet I just finished the first milestone. The base for the test runner is going to be QxRunner, however this didnt have a test suite of it's own, yet. By coding this I achieved a double purpose (i) get to know the internals inside out and (ii) create a safety net for comming changes.

The initial goal was 90% coverage, although it never got specificied what kind of coverage, be it class, method, block, statement, branch ... In the end I achieved 70% line coverage which is a whole lot indeed. The remaining bits werent really worth exercising imo, view report. I measured this with gcc's gcov and visualized it with lcov.

Acceptance!

The accepted Google Summer of Code projects have just been announced and ... my xUnit Kdevelop4 related one got through! It is happening :) Getting paid by google to hack on KDE, just great.

Andreas Pakulat is going to be my mentor. He is an experienced Qt and KDE developer, whats more he gets paid paid to code on test related software: squish . The right person for the job for sure!

Fetch python

My second, slightly preferred, proposal is related to Fetch. I've contributed to the project and use it for my Bachelor year assignment, Tsmells. Fact extraction for python would be awesome, to say the least.

The goal of this project is python support for Fetch. Fetch is an open source tool chain which performs static analysis on object oriented software systems. Use cases include architectural conformance checking and re-documentation, model querying by developers, internal quality trending and effort estimation based upon static analysis. Currently C/C++ and Java are accepted as input languages.

Since UA is not a mentoring organization (did not apply), I submitted this proposal as a 'no_org'. Bart Van Rompaey has agreed to mentor me on this.

Kdevelop application

As part of a greater scheme - promote testing in FOSS - I want to code state of the art xUnit support for kdevelop as a gsoc.

Here's the abstract:

The goal of this project is support for xUnit frameworks in Kdevelop4. More specific: QtUnit, CppUnit, Check and PyUnit.

Automated testing with the aid of xUnit frameworks is popular and known to have a positive influence on software quality. However, IDE plug-ins are fairly rare. With good tool support writing and running unit tests can become more efficient and fun. Since xUnit frameworks share a common structure, a generic approach is feasible.

Fingers crossed.

Setup

This will primarily serve as a log for google summer of code related stuff.