Code review comment for lp:~kampka/testtools/test-to-fixture

Yes, my fixtures are on occasion very tightly integrated with tests. As a matter of fact, I usually tend to perform most of my test setup within the fixture to make the fixtures behavior consistent when used in multiple test cases/scenarios. In my opinion, this leads to a more complete set of fixtures and a cleaner, easier and more straight forward way of writing tests, but it also means of course that you need to be able to interact with your test from the fixture and vice versa, eg. fail / skip it for some reasons, perform fixture analysis on addOnException calls.
One main reason for this is that some of my fixtures are very expensive to set up because the require parsing large files or because they tap into remote resources, so setting it up from scratch for every test would result in very slow test suite execution. I even find my self in positions where I find it acceptable to share fixtures between tests and even test cases to reduce setup cost, eg. call a slow remote service and use that data on multiple tests. This results in an even tighter integration, eg. "if one test from testcase.id() fails, fail all others" or "if fixture.setUp() fails, skip all tests".