Testing and testability in KDE PIM

[Denis Kurz]

Today's the perfect date to bring up a scary topic: Testing!

Dan commented this on a recent Diff:
> And you are right, we should have more tests to cover this

I thought that, too, just some days ago, when I tried to get my head around 
Akonadi's FetchHelper. I felt that changing anything there, even apparent 
style changes, might break things. After all, I don't have a very deep 
understanding of the context this class is used in and methods are quite long: 
fetchItems is only the tip of the iceberg, with its 340 lines.

I assumed that tests might help, and was confirmed by introductory part of the 
book [1] I then started to read. Let's assume for the rest of this mail that 
that book keeps me motivated to actually do something about test coverage in 
KDE PIM.

Here are a few questions that came up so far:

* How are chances to get patches through review that merely improve 
testability, without introducing actual tests? Note that improving testability 
can mean more code without adding user-facing features, and it might add a 
layer of indirection or two where it hasn't been needed so far. I consider 
testability as a feature, though.

Rationale: I wouldn't want to put time into writing tests against an interface 
that is never coming because a patch I'm depending on is not accepted.
I assume chances are rather high, as D15727 seems to get accepted, too, and I 
haven't seen a Diff so far that was rejected. Just want to be extra sure.

I will try to refactor as little as possible as long as there are no tests to 
lead the way, as preached e.g. by Fowler [2] and Feathers [3]. When the time 
comes, the above question also applies to refactoring, too: How are chances to 
land mere refactoring changes, like extracting a small method from a larger 
one just to give it a name; giving classes, variables etc. meaningful names; 
port to newer C++ features like moving declarations to "const auto", nullptr 
etc.

* There seem to be several studies that show that, typically, "90% of the bugs 
are found in 20% of the code". This quote from Roy is followed by the advice 
to ask the team to point to those 20%. So: Can you identify any parts of the 
code that might benefit from testing and refactoring more than others? 

* The other way around: Since I'm still an absolute beginner in testing, can 
you point to components that might not be too hard to refactor, but would 
still benefit greatly? A refactoring and testing junior job, if you will.

* I figured so far that in KDE PIM projects, "autotests" are meant to be unit 
tests (testing a unit of work in isolation; no configuration or interaction 
needed), while "tests" are more like "integration tests". Is that correct?


Right now, I'm especially interested in Akonadi, but components in KOrganizer 
or some of the libraries it uses would be interesting, too.

Happy Halloween,
Denis

[1] Roy Osherove: "The Art of Unit Testing"
[2] Martin Fowler: "Refactoring: Improving the Design of Existing Code"
[3] Michael Feathers: "Working Effectively with Legacy Code"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20181031/d0ac3a11/attachment.sig>