The author fails to justify why he "hates mocks" except a hand-waving justification of "they don't test production code". Well, they do, other than the parts that are mocked. They "don't test production code" in the same way that his unit test doesn't test production code because it only touches a fraction of the real code.
I don't disagree with his decomposition, it's correct. I also agree with his approach to unit and integration testing to touch the appropriate layers. It's just his knee-jerk and unjustified hatred of mocks I'm objecting to.
Yeah. I completely agree with the part about separating db stuff and logic (it's a huge pet peeve of mine and almost nobody at work does anything like that), but I think mocks do have a place.
I also think it's best to make sure the majority of our code doesn't require mocks to test. But very few people do that either even if it's fairly simple.
I am fairly fresh with my two years of professional experience and I've spent a lot of energy worrying about whether there's something wrong with me that makes me want to refactor most of the code I read. I'm starting to lean towards the conclusion that it's not my fault, it's just that most devs write shitty code.
This is a bad way to validate data. It generally means that any new data added to this type won't be validated by default. It isn't too bad because it is a typed native data structure (must worse in things like JS where extra fields can slip in from the JSON) but it is better security practice to parse the data rather than just looking at it. So it would look something like this
func validateUser(user User) (error, User)
Then the function carefully extracts and validates the input before copying it to the output. Anything that it doesn't know about doesn't get copied. This can be thought of as "whitelist validation" rather than "blacklist validation".
If we're going that route, just forbid making User objects which are not valid. Hide the fields, force the instances to be immutable, validate in the constructor, problem solved. Does not work in things with duck typing or anything remotely resembling the two most used programming languages in new projects in the industry. But for traditional statically typed languages, it's a good solution. Now a function taking in a user is literally incapable of ever taking in an invalid user, assuming your tests for the class are good and pass.
Exactly - if you have Xs that are foolike, and Xs that are barlike, the perhaps you should have Yz and Zs instead.
Further, if you want to validate that your X is barlike, all you have to do now is make sure you have some function f : Y -> Z. If you want to scrutinize your validation logic, then you need only look at all functions of that specific type in your program.
Admittedly, go is probably not a language with the best support for these kinds of constructs.
I've found the best to test everything from the http handler to database in one test. Unless you want to write 5 different tests for each endpoint. In one project we've run the tests against in-memory db and production was postgres. Of course there was a bug caused by different SQL implementations. Other time, we've tested only the the service layer (the fiddling part worth testing), skipping the spring boot controller. Of course there was a bug caused by bad annotations at the controller layer.
I don't disagree with his decomposition, it's correct. I also agree with his approach to unit and integration testing to touch the appropriate layers. It's just his knee-jerk and unjustified hatred of mocks I'm objecting to.