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: