Hacker News Reader

Comment by gegtik | Hacker News Reader

given that some test people might be reading these comments - is anyone aware of a configuration for test frameworks that: 1. lets users opt code out of the testing footprint (I know this is a given), but also 2. monitors opted-out code for being called a certain number of times, therefore meaning it's depended upon, therefore meaning it SHOULD be tested, and gets flagged?

I feel like this would be the way to go to minimize non-valuable testing while allowing you to discover code thats becoming more leveraged and therefore more critical to test.

View on HN

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?

Thanks for the reply;

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.

What do you mean by opt code out of the testing footprint? Can you give some examples and why?

Reply on news.ycombinator.com