Ian Jackson <[EMAIL PROTECTED]> writes: > Esteban Manchado Velázquez writes:
>> I meant functional vs. unit tests. I guess it doesn't make sense to try >> to run unit tests in the installed system, partly because the sources >> aren't available (one would have to do "apt-get source dpkg" or >> something like that)... and because the unit tests should pass >> regardless of the installation. But I just wanted to confirm :-) > I'm afraid I don't know what the distinction is that you're making. > `Functional tests' and `unit tests' are jargon from test-obsessed > people :-) that I don't understand, so you'll have to explain it to > me. 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). An example of a functional test would be installing a variety of possibly oddly broken packages to be sure dpkg's error handling works properly. An example of a unit test would be a test suite for the functions that do dependency analysis. Unit tests are useful because one can take the code apart well enough to simulate error conditions and weird inputs that might be difficult to construct via the public interface but which some internal bit of code should be able to handle (and because they're often easier to set up and reason about). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>