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

List:       gtk-devel
Subject:    Re: Gtk+ unit tests (brainstorming)
From:       Havoc Pennington <hp () redhat ! com>
Date:       2006-10-25 16:32:08
Message-ID: 453F9188.7000705 () redhat ! com
[Download RAW message or body]

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. It gave percentage basic blocks tested, globally, by module,
    and by file. Then for each file, it did the gcov-style annotation
    to show what was not covered.

    So when coding, you could make coverage report, then see what you
    had failed to test. Also, if you just wanted to work on improving
    test coverage, you could use make coverage-report to find
    areas to work on.

    the coverage-report target simply depended on make check, so it
    was only a single command to run all the tests and look at
    their coverage in a helpful format.

  - 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.

  - 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).

    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.

Havoc

_______________________________________________
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]