Re: Gtk+ unit tests (brainstorming)

[Tim Janik <timj imendio com>]

On Wed, 25 Oct 2006, Havoc Pennington wrote:

> Hi,
>
> When coding dbus I thought I'd try a project with a focus on unit tests.
> It has (or at least had for a while) exceptionally high test coverage,
> around 75% of basic blocks executed in make check. The coverage-analyzer
> has been busted for a couple years though.
>
> Here are my thoughts from dbus:
>
>  - the "make coverage-report" was by far the biggest win I spent time
>    on.

ah, interesting. could you please explain why you consider it
such a big win?

>  - frequently I needed to add extra interfaces or levels of
>    abstraction to be able to test effectively. For example,
>    allowing "dummy" implementations of dependency
>    module to be inserted underneath a module I was testing.
>
>    dbus is heavily conditionalized on a DBUS_BUILD_TESTS
>    parameter, which allows adding all kinds of test-only code
>    without fear of bloating the production version. One price
>    of this is that the tested lib is slightly different from the
>    production lib.

ah, good to know. though i'd consider that price considerably high for a
project of the size and build time of Gtk+, and where we'd really benefit
from having *many* developers and contributors run make check.
especially, when you have a quite large legacy code base, instead of
developing with conditionalized test hooks from the start.

>  - based on how nautilus does unit tests, I put the tests in the file
>    with the code being tested. The rationale is similar to the
>    rationale for inline documentation. I think it's a good approach,
>    but it does require a distinct "test build" (DBUS_BUILD_TESTS).

sounds interesting as well. the downsize is of course the assorted
file growth, and gtk+ already isn't a particularly good citizen in
terms of loc per file ;)

$ wc -l *.c | sort -r | head
  380899 total
   14841 gtktreeview.c
   11360 gtkaliasdef.c
    9154 gtkiconview.c
    8764 gtkfilechooserdefault.c
    8632 gtktextview.c
    8060 gtkwidget.c

>    Another advantage of this is that internal code can be tested, while
>    it may not be possible to fully exercise internal code using the
>    public API.

thanks for your insight havoc. i'll definitely look into the coverage
report generation at some later point.

> Havoc

---
ciaoTJ