undefined | Better HN

0 pointslmm2y ago0 comments

Sounds like some kind of protestant work ethic mentality: testing should be hard work, the harder writing your tests was the better your soul and the better your system.

I've seen plenty of projects that made oodles of mocks and fakes and unit tests and just sucked, outright didn't work at all in a way that would've been obvious if they'd done testcontainers-based integration tests or even just manual testing in prod. I would absolutely trust a project that was written in Haskell and had no tests, or only integration tests, ahead of one that had lots of unit tests. Indeed if anything I'd say the number of mocks/fakes is negatively correlated with the actual project quality.

0 comments

sverhagen2y ago

Just to add, there's also a (Chicago) school of thought that pushes back against mocks and fakes, so even if you're religiously (to stick with the metaphore) writing unit tests, you might still not invest in mocks and fakes.

Mavvie2y ago

Can you (or someone else) explain what the alternatives are? How can I write unit tests without mocks or fakes?

hyperadvanced2y ago

They might mean that rather than using a mock, use a real typed object/instance of a real thing and inject it into the unit that you’re testing. Admittedly, that might meet the definition of a fake/mock once you get down to the level of testing something that needs db access. Another way of interpreting that is that you can use in memory versions of your deps to mirror the interface of your dependency without needing to repeatedly, and possibly haphazardly mock certain functions of your dependency.

j / k navigate · click thread line to collapse

0 comments

sverhagen2y ago

Mavvie2y ago

Can you (or someone else) explain what the alternatives are? How can I write unit tests without mocks or fakes?

hyperadvanced2y ago

j / k navigate · click thread line to collapse