Re: Dpkg testing framework and Ubuntu's automated testing
Ian Jackson <ian@davenant.greenend.org.uk> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: