But why?
Maybe there's some fundamental difference of opinion here, because I'm thinking definitely not, no way, test-only code paths should never reach prod, and code that ships should never even know that testing is a thing that happens.
The code has to be written so it takes in the altered unit via parameters or other DI or so it knows that the current system is set to short circuit some calls.
Ie, you could have MyClient(testHTTPClient).GetResource(foo) used in tests and MyClient(realHTTPClient).GetResource(foo). The testHTTPClient would get to the actual connection part and return a configured response or error.
Your entire logic is the same, your code could "receive" a forced 404 or timeout or 200 OK. It is up to the testHTTPClient that is only changing how the http connection is handled.
I call these unit-integration tests. You are checking all units work together while not actually working with the outside world.
Can you square those for me? I don’t get it.
I have an example where a coworker used constants from production to assert return values. I stated that the test can‘t use them because the test is the specification and needs to be in control what is correct and what is not. Even if that means we write duplicate string values. In this case somebody changed a const value to a wrong value. But for the test this was all fine.
i did something like this where in production I have if function pointer isn't null return the result of it instead of running the production code (and an unlikely compiler directive on the if). The function itself is implemented in a test only shared library so the cost to production is low. If you can break in you can set that function - but if you can inject arbitary code we are already sunk.
What's your reasoning for this? As a counter-example, the hardware you are using right now almost certainly has test points throughout the circuitry. Beyond all the uses the test points get during development and manufacturing, they are essential for repair and re-calibration after being sold to the customer and put into production.
Though some would still prefer the tube. That's up to them.
Service tubes and jack points and JTAG and whatever ship in physically assembled artifacts because they have to, not because they should.
In-situ fault testing and isolation is an engineering principle that per pervasive across many domains. You want your auto manufacturer to rip anything related to tell you why it doesn't work?
You are just trying to defend a previous opinion by throwing out some acronyms to dress up your argument.
They should spin two boards, one with jtag and one without and then how would they debug the board they just removed the jtag on?
All systems are dynamic, all reliable dynamic systems use feedback, but you are arguing that engineers would rather remove those feedback mechanisms?
The fallacy meter just cracked.
I'm genuinely sorry if it's frustrating, hopefully not, but I'm exiting this conversation now.
It sounds counter-intuitive, but IMO with this strategy you ship way less production code.
if the test differences are significant I would agree to not pollote production but often they are not so the harm is minimal.
Why? Humanities most reliable engineered objects contain their own test and monitoring systems.