←back to thread

294 points NotPractical | 2 comments | | HN request time: 0.404s | source
Show context
xnorswap ◴[] No.41856752[source]
> Redbox.HAL.Configuration

> .ConfigurationFileService implements IConfigurationFileService

> STOP MAKING SERVICES AND FACTORIES AND INTERFACES AND JUST READ THE FUCKING

> JSON FILE YOU ENTERPRISE FUCKERS

I know it's cool to "hate" on OO, but "just read the fucking file" doesn't work if you want to run your unit tests without reading a fucking file.

It makes sense to abstract configuration behind an interface so you can easily mock it our or implement it differently for unit testing.

Perhaps you also want to have some services configured through a database instead.

This isn't a ConfigurationFileServiceFactoryFactory.

replies(12): >>41856822 #>>41856831 #>>41856836 #>>41856965 #>>41857895 #>>41858054 #>>41859117 #>>41859509 #>>41859750 #>>41859882 #>>41860221 #>>41864182 #
rcxdude ◴[] No.41858054[source]
But why is it so hard to read a file during a unit test? Files are pretty easy to mock in many different ways, all of which are pretty fast. You don't need a special-purpose interface to be able to test the code that uses a config file.
replies(3): >>41858083 #>>41858297 #>>41858623 #
stickfigure ◴[] No.41858297[source]
Let's say you want to test bootstrapping your system with various configurations.

You could make a few dozen different configuration files. Or maybe it's more than that because you want to test permutations. Now you're maintaining a bestiary.

So instead you think "I'll write code that generates the config file for each test". And that's reasonable sometimes.

On the other hand, the single-responsibility principle can be reasonably applied here and "reading the config data" is a good single responsibility. You don't want to have to write code to muck with json or xml every time some component needs a configuration value. So there should already be a clean boundary here and it often makes sense to test the components separately.

There's not one rule. The article author sounds like an excitable jr engineer that's never written software at scale.

replies(3): >>41859388 #>>41860580 #>>41861658 #
dogleash ◴[] No.41859388[source]
> that's never written software at scale.

Is this like a never version of that insult where people would say someone's opinion doesn't matter because they worked on a project that never shipped (regardless of how much or how little they contributed to the failure)? Just replacing it with an AWS bill-measuring contest?

replies(1): >>41861108 #
1. stickfigure ◴[] No.41861108[source]
"Software at scale" is different from "data at scale" is different from "compute at scale".

But yeah, when I hear "STOP MAKING SERVICES AND FACTORIES AND INTERFACES AND JUST READ THE FUCKING JSON FILE YOU ENTERPRISE FUCKERS" I think "developer who's never worked on anything more complicated than a chat app, and isn't old enough to have learned humility yet".

replies(1): >>41862509 #
2. ◴[] No.41862509[source]