Hacker News Reader

Comment by tyingq | Hacker News Reader

"Test-specific production code. Some code needed for the tests is written as tested production code, particularly for infrastructure classes. It requires extra time to write and adds noise to class APIs."

I don't see this much in real world code. Is there a space/niche that does this extensively? Does it raise a bunch of arguments about anti-patterns, etc?

View on HN

I think it depends on where you draw the line. In C# it's very common to use interfaces even though you only ever expect to have a single class of the given type, just so you can stub it out in tests.

It's unfortunate, but some languages require you to do at least some re-architecting so it's easy to test your code.

WIthout reading the article, I'm on the "testability is a first class design criteria".

Ease of testing should absolutely affect all your production code design choices.

That said, there are terrible ways to do that, as always.

Interfaces have other advantages as well, that is an added benefit.

Implementing a No Op version of an interface for tests or a simple version that uses a map instead of db calles has a lot of benefits.

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.

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

In my personal experience I’ve been more prone to expose test specific code in implementation than my teammates, but even so:

- it’s usually to export things which are project internal (and create references where they’re magic numbers etc otherwise) specifically to decouple tests

- otherwise it’s been basically some lighter weight version of the null wrapper

And no one has complained. Perhaps they should but I think it hasn’t been an issue because my devotion to automated testing has been more thorough and thoughtful than many of those who’d complain, and they’re happy to benefit from the safety that provides.

Honestly I think test and implementation code should be more tightly coupled not less. At least in terms of being able to reference things that are clearly project-/package-private. I know this would bother a lot of people depending on discipline, but it’s pretty much exactly what people do in many Rust projects and seems pretty successful.

It is a lot eaiser to make an interface and throw a mocking framework at it. I've been thinking of similar ideas for a while, but implementing them is hard so I never tried it.

Reply on news.ycombinator.com