[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Gtk+ unit tests (brainstorming)
From:       Tim Janik <timj () imendio ! com>
Date:       2006-10-30 14:34:32
Message-ID: Pine.LNX.4.62.0610301527400.25336 () master ! birnet ! private
[Download RAW message or body]

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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]