Ian Jackson <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
