←back to thread

Good Software Development Habits

(zarar.dev)
362 points mmphosis | 4 comments | 17 Nov 24 16:34 UTC | HN request time: 0.833s | source
Show context
normie3000 ◴[17 Nov 24 18:49 UTC] No.42166033[source]▶
Alternative to #10: avoid mocking.
replies(1): >>42166862 #
mdaniel ◴[17 Nov 24 20:22 UTC] No.42166862[source]▶
I believe there is nuance to this: how else would any sane person exercise error flows in software, or -- as I have personally implemented -- test against things which are wallet-expensive in real life?

What I oppose is mocking every single dependency of every single injection in the component. It ends up being 50x the code of the system under test and requires throwing it all away when the implementation changes

replies(2): >>42167531 #>>42171729 #
1. necovek ◴[17 Nov 24 21:36 UTC] No.42167531[source]▶
Unfortunately, most "frameworks" in existence today do not follow a simple, functional design, and they tend to make you mock quite a bit.

But the alternative to "mocking" is to use verified fakes (same test passes for both the real implementation and the fake) that actually do something "real" (even if it's simply persisting data in memory).

replies(1): >>42168162 #
2. mdaniel ◴[17 Nov 24 23:07 UTC] No.42168162[source]▶
My complaint about using "real implementations" (aside from databases, which, sure, knock yourself out with testcontainers or even hsqldb running in compatibility mode[1]) is that managing the state of real systems is incredibly hard. I am aware of aws-nuke and its kin, but tearing everything down and then setting everything up for every test cycle consumes very real wall clock time and the flakes drive up "test fatigue" where folks start merging things with test failures because "oh, you know, it's just kidding" or the deadly enemy "we don't have time to wait for the test cycle, we need the fix out now!"

I am 100% with you on the verified fakes and love moto (and its friend localstack) for that reason. If I had lottery money, I'd even go so far as to create a moto-eqsue implementation backed by lxc or such and have it actually provision/mutate some running infra that I can snapshot and restore

1: https://www.hsqldb.org/doc/2.0/guide/compatibility-chapt.htm...

replies(1): >>42179410 #
3. SAI_Peregrinus ◴[19 Nov 24 01:58 UTC] No.42179410[source]▶
It's especially hard for embedded software. You certainly do want hardware-in-the-loop tests, but you also want tests that are independent of the hardware. You have to simulate the hardware interaction, and you definitely want to verify what the code tried to do to the hardware, and when. So for the hardware-interacting layer you want mocks, not just fakes.
replies(1): >>42180380 #
4. necovek ◴[19 Nov 24 05:44 UTC] No.42180380{3}[source]▶
Just imagine a world where a component manufacturer (be it hardware or software) also provides a verified fake/simulated implementation.

Even hardware, they likely did develop it using software simulations: they just need to ship it with their SDK. Another thing hardware has it going for it is that it does not change as much.

Note that a verified fake could still have observability points that allow you to monitor what's going on.