> So much precision is required that session musicians are playing most of the things you hear, not the actual artists

I’m sure the session musicians don’t appreciate this statement. Just because they can play with high precision and reliability doesn’t mean they are playing without soul.

If the featured artists can’t do so on their own, that’s sort of a knock on them, isn’t it?

So you have available all of the original Pokémon

I have a hard enough time getting humans to write tests like this…

https://go.dev/blog/loopvar-preview

Your code ends up using the driver raw in these cases, so why not just use the driver for everything? Your codebase would be consistent at that point

Perfectly fair. I shouldn’t have stated it as an absolute. If I could still edit it, I would change my statement to “don’t default to a mock”

> Would you mind explaining what you mean here

Gladly. Martin Fowler provides really clear definitions for the different types of test doubles.

https://martinfowler.com/articles/mocksArentStubs.html

Maintaining that your Fakes are correct takes work. An easy way that I’ve found to do that is to run the tests against a “real” component and the Fake component with the exact same set of assertions and set up. If that test breaks, then you know that consuming code should also break

This problem is exacerbated if B is a popular object used by many components.

IMO if you own A and B, never use mock. Possibly write a Fake B if B is non deterministic or slow. Then write a parity test for B and Fake B

You can disable it like any other plugin though? Really easily? And it’s a paid service. Just don’t pay for it.

Seems like rage bait that a lot of people are falling for.

Of course, if it turns out it’s phoning home with training data by default then I will also change my tune, but it doesn’t seem to be doing that

To make an analogy to music, I see it like brass players at the advent of the valve.

It’s a new way of playing the instrument. The old ways and new ways aren’t congruent in all ways, but the new way does seem to have a higher skill ceiling

The go ecosystem frequently utilizes `go generate` to handle boilerplate code generation. That’s the exact same way `thiserror` utilizes macros to generate plain error structs. While macros can do more, in this case it’s the same.

The former is just macros for error definition

The latter is just a wrapper around box dyn error