I agree with you guys to a certain extent, but doing so only complicates
my setup procedure to the extent that I'm calling a lot of my teardown
code in a dumb manner, unless I actually kept track of how far into the
setup process I got before everything went awry and split it into a
multistep rollback process for atomicity.

This in and of itself seems like a lot to track with complicated
processes like configuring a daemon interactively via pexpect, or
modifying a remote VM instance with multiprocessing being used for
injection, and I don't know if I can expect consumers of my test suites
to get it right twice.

Could you guys provide some examples of existing test suites where this
may potentially break things?

Thanks!
-Garrett