1. In any testing framework I've used, this is (as you said) a given. The exact mechanism you have for slicing and dicing your tests varies, but this is usually well supported IMO.
2. This feels like the job of a code coverage tool to me (and it's something I would like as well), but most coverage tools I've seen don't quite have the granularity you're looking for. In certain ecosystems you could hack something together pretty quickly (e.g. the `trace` module in python).
Correct me if I'm wrong, but this idea sounds like you'd like to bias your tests away from small units and toward integration tests (and a similar tool could be useful for dead code elimination and a few other tasks). I know they're not a panacea in general, but in your personal experience what problems have you found in fine-grained tests that outweigh their benefits?
I'm a believer in "right-sized" testing, meaning balancing the cost of test creation and updating against the value the tests provide. I believe tests provide the greatest value when they are testing:
* public methods
* critical business logic
* highly reused core logic
in other words, "code for others".
For code that's used for one specific page render or something similarly isolated, I think it's more questionable whether to bother going for 100% code coverage.
The latter category is where I'd like to "trust but verify" with devs permitting them to opt out of unit tests where they believe the code isn't critical, but have some confidence that we would catch code if it became more central and then enforce testing requirements.
I could see something like this being extremely useful when working with legacy code. In the book "Continuous Delivery (Humble, Farley)" they suggest when working in legacy code without tests, to begin adding testing to systems starting only with the parts you changed. If this is hard to determine, a test feature that shows unit dependencies could be really helpful.
2. This feels like the job of a code coverage tool to me (and it's something I would like as well), but most coverage tools I've seen don't quite have the granularity you're looking for. In certain ecosystems you could hack something together pretty quickly (e.g. the `trace` module in python).
Correct me if I'm wrong, but this idea sounds like you'd like to bias your tests away from small units and toward integration tests (and a similar tool could be useful for dead code elimination and a few other tasks). I know they're not a panacea in general, but in your personal experience what problems have you found in fine-grained tests that outweigh their benefits?