Neither example is easily tested.
Neither support injecting the dependencies, which make mocking really difficult.
On the left, you're testing one big method with a whole bunch of conditionals, which leaves you with a whole ton of tests for that one big method.
On the right, there is a bake() method and it does oven.New(), but where does oven come from? Is it some global somewhere?
Pass in an order, assert the pizza that comes out is correct.
The entire function is a unit which can fit on my phone screen and has no external dependencies other than possibly oven, which was discussed in the article, it should probably have been passed in, aka dependency injection.
It isn't necessary with golang to do this at all, but it really helps build consistent structure throughout the entire app, so I do it.
Speaking from personal experience. I built a small golang process that ran on around 25k worker machines. It had to be bug free cause if it crashed and stopped running, it meant updating a whole lot of computers across multiple data centers, by hand.
We unit tested everything and the project worked out really well because of that.
Why would you care where the oven comes from, if the function deliver perfectly baked pizza? A unit test should test against the public interface and not be coupled to implementation details, since that will hamper refactorings.
> which make mocking really difficult.
Mocking is an antipattern anyway, and should be avoided except for nondeterministic components like current time or stateful external services.
> The code that is more easily unit testable, is the code I care about.
Author argues that his code is more readable. Sounds like you're saying that being unit-testable is more important than being readable.
> Neither example is easily tested.
Only if you're a unit testing zealot. Integration/E2E testing is easy for both.
> Neither support injecting the dependencies, which make mocking really difficult.
Mocking is not a virtue. Also, if mocking is the sole reason you're using DI, you're doing it wrong.
Come on, look in the mirror.
Functions should exist at the level of concepts:
1. arr | flat | map | collect as HashMap makes sense.
2. CreateFlattenMappedHashMapFromArr does not.
boxPizza should take a CookedPizza, and BakePizza should take a RawPizza and return a CookedPizza etc.