That's the trick - it is not test only code. You use the same objects, the same code.

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.

You’re responding to a comment containing a method call `thing.makeThingDoerForTest(1, 2, 3)` and saying “That's the trick - it is not test only code.”

Can you square those for me? I don’t get it.

It goes a bit into the same direction rust went by shipping the unit tests usually inside the module. The thought is intriguing to keep the „mock“ setup up to date even when doing refactors. But I wonder if this solves the issue. I tend to not use mocks. And I try to stay away from spies. These two tie the tests to close to the implementation like the article also described. The reason why I don‘t ship test setup in production code is the simple fact that the test / spec should not be based on production code. Hard to put in words for me but the test should be impartial. It sets up its test world and run the subject in it. It should not use the subject to describe the test environment. I think this will lead to false positives.

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.

What is the harm in a test only path in production? If you are an embedded systen with limited memory there is obvious harm but most code isn't that. There are other possible harms but they are less obvious and may not imply. There are also many different ways to implement this.

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.

`makeThingDoerForTest` is a standalone function (or static method) that never gets called in production code. I don't see why it needs to be in an entirely separate module. If you want, you could put it in a separate thing_test module, but then you'd have to expose a more powerful constructor for thing_test to access. I'd rather hide that inside the thing module, and I see no benefit to splitting this functionality across two modules just for the sake of not mixing my peas with my potatoes.

> 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.

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.

So much needless discussion because someone makes an ill thought out hot take. Most engineered objects of any substantial complexity include built in test systems. They would be impossible to build without them.

If civil engineers could launch their dams in debug mode instead of flying out and crawling through a tube, I think they would. They just can't.

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.

No, you are wrong.

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.

The answer to your needlessly aggressive questions is, no, of course not. None of that is anything I'm saying.

I'm genuinely sorry if it's frustrating, hopefully not, but I'm exiting this conversation now.

I guess overcoming that dogma is exactly the tradeoff.

It's just a feeling, not a dogma. I'll happily throw it away. But why?

Not needing polymorphism, interfaces, DI frameworks or auto-mocking, IMO.

It sounds counter-intuitive, but IMO with this strategy you ship way less production code.

Call it demo mode and it will become more important than the real to some of you company.

if the test differences are significant I would agree to not pollote production but often they are not so the harm is minimal.

> test-only code paths should never reach prod

Why? Humanities most reliable engineered objects contain their own test and monitoring systems.