Re: Gtk+ unit tests (brainstorming)

On Wed, 25 Oct 2006, Havoc Pennington wrote:


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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]