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