2 ms·
I've seen it (and, ahem, have written it...), but it's a rare sort of antipattern that I think mostly happens with inexperienced developers. I haven't had to d
by ravenstine 5y ago
I've seen it (and, ahem, have written it...), but it's a rare sort of antipattern that I think mostly happens with inexperienced developers. I haven't had to do such a thing in several years except when there was some weird framework/library limitation where I was semi-forced to write a little test-specific code. Test-specific production code usually is a crutch to work within weird situations ultimately caused by dogmatic adherence to object oriented principles where there's the potential for inaccessible state all over the place; if something is getting in the way of tests that you only have coarse-grain control over then having `if (env == "test")` acting as a glorified `jmp` instruction might result in either making something testable or at least faster to test. Experienced developers that are at least halfway decent, rather than use such a crutch, instinctively consider whether the situation they are in is caused by stupid design and correct for the issue at a higher level; if they've always managed to think this way (i.e. like an engineer) then it may never occur to them why anyone would write test-specific code other than perhaps feature flags.
- omegalulw 5y agoIt's not always an antipattern. Another example would be a public API that exposes more state/info than it's users need, just for better tests. It's still kind of not the best practice, I will concede, since almost always you want to focus on testing the contract, but sometimes, exposing some extremely critical state info is ok to improve tests.