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

Re: Dpkg testing framework and Ubuntu's automated testing

Ian Jackson <ian@davenant.greenend.org.uk> writes:
> Russ Allbery writes:

>> Functional tests generally test some user-exposed functionality of the
>> package and therefore usually don't require access to anything other than
>> the public interface of the package.  Unit tests are tests of specific
>> internal components and therefore frequently exercise internal APIs and
>> have to be built as part of a built source tree (rather than applied to
>> the final binaries).

> Thanks for the explanation; that's more or less what I thought but it
> didn't seem to apply: I don't think there are any unit tests for dpkg.

> Most of the internal functionality is reasonable accessible and
> testable from the external interfaces, so I don't think inventing a
> bunch of unit tests would make a great deal of sense.

I don't think I've ever found a piece of software where I didn't want to
write unit tests -- there aren't any internal data structure
implementations, internal functions (such as dependency analysis) with a
well-defined API, or anything similar?

Unit tests provide a lot of bang for the buck for portions of a code base
that one can then treat in isolation.  They help a lot with hammering out
the interfaces of internal modules and utility functions.  I write unit
tests for all generic utility code (error reporting functions, memory
allocation wrappers, hash tables, etc.) as a matter of course so that I
can be sure I've gotten all the edge cases in the interface.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: