I'm talking about testing a package that you're building, especially one that spawns a daemon and/or fiddles with init.d.
Do you log into some sort of chroot? Do you create a virtualized distribution and tear it down? How do you test your runtime dependencies and test suite without fouling up your dev machine for the next time you run your tests?
A virtualised machine, which you reset to a "clean" state after testing, would be the easiest. VMWare and Parallels "Snapshot" features is perfect for this..
You would install Debian or Ubuntu, then take a Snapshot (How-to for VMware and Parallels). Then you'd install your package and test installing, using and removing it.
Once you are done, it's trivial to restore to the snapshot you took (far quicker than reinstalling completely)
I personally use my own machine during development of packages. This is not possible if you are packaging for older distributions but it's a lot quicker than using any other solutions if there is a lot of churn on your packaging code.
To test package builds, you need to use a chroot-based tool like pbuilder, cowbuilder, or sbuild. This makes sure that the package will build with correct dependency on the target distribution.
You can test some software in chroot, but things like network daemon make come into conflict with other daemon running on the host machine.
If your package set is complexe, the best test environment you can use is a VM software that supports snapshot. You need to create a virtualized environment with your target distribution and install package on it. With snapshots, you can reset your operating environment back to its post-installation state.
You can work with only one snapshot, but VirtualBox supports multiple snapshots, which give additional flexibility in complex tests.