Unit Tests

[M Breugelmans]

On Sat, Sep 13, 2008 at 3:20 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> Hi,
>
> I've recently felt really uncomfortable when doing some coding on a new
> component at work. The reason was that we already have quite some code
> there, but still lack unit-testing for some core parts.

Yep a safety net pays off when making changes to existing code,
assuming the test code is high quality. Low quality can actually be a
burden. For instance test-maintenance could become huge when the test
heavily relies on unit-under-test internals.

> Hence I'm writing this post. I think we all agree that we're seriously
> lacking unit-tests, I know that duchain/c++ has tests, also cmake
> support has some tests and qmake as well. The new test-plugins also have
> tests. However the core parts lack them, that is the majore libraries in
> kdevplatform.

Sublime has strong tests as well.

> I know and understand that writing tests might be boring (though I have
> to admit that it can be fun too - try to think of it as an excercise on
> breaking other peoples code), but I think if everybody tries to do a
> little, we can already get quite some more coverage.

It is only boring if test are written after the code, because then
it's a chore. Test-first is actually a lot of fun. It also leads (by
definition) to testable code, low coupling, good api, instant
feedback, a progress indicator, non-bloated code, high productivity
and obviously few bugs. It does require a mentality shift and
self-discipline though.

I'm not just making this up ;) Other people that write test first
think alike eg

http://googletesting.blogspot.com/2008/09/test-first-is-fun_08.html
http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Personally I couldn't go back to vanilla development.

> So I'd like to ask what you all think about the following guidelines:
>
> 1. If you find a bug and fix it or work on a bugfix for a reported bug,
> write a unit-test for it first.
> 2. If there's infrastructure missing to create such unit-tests, lets
> discuss how we can create that infrastructure
> 3. It would be nice if everybody could spare an hour or two of
> development time every other week - or once a month or something and use
> it for test-writing.

+1

> With that I think we might be able to increase the test coverage of our
> code-base quite a bit.

Coverage is not the best metric, you can have 100% coverage without a
single QVERIFY.

> Note that not only unit-tests on individual
> classes are important, integration tests could also be useful.

Yea, units that behave correctly on their own are worthless if they
don't cooperate correctly with the rest. Integration, subsystem and
system tests fill that gap. Preferably automated (scripted?).


Manuel