this post was submitted on 05 Aug 2023
692 points (97.9% liked)

Programmer Humor

32371 readers
572 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] argv_minus_one@beehaw.org 2 points 1 year ago

Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what’s the difference between a spy, fake, stub, mock, etc.

Oh good grief. I haven't even heard of half of those, and I've been writing code longer than most interviewers.

Also doing it with dependency injection and all that.

After struggling with several DI frameworks, I've come to the conclusion that DI is far too opaque and unpredictable to be useful.

OOP is also intentionally opaque, mind you, but debuggers can see through it if necessary, so that's fine. DI, on the other hand, is opaque even to debuggers!

I much prefer having an in-memory database than mock what a database does.

I much prefer using the same DBMS for tests as the one used in production. That way, I can use its special features (like arrays as query parameters), and avoid bugs resulting from differences between DBMSes (which would only appear in production).

You obviously can’t always get replacements for things and you’ll need to mock and I get that. I just prefer to not use them if I can.

Indeed, and you usually can. Even if your system involves a bunch of services that normally run on different machines, who says you can't spin up instances of them as part of the test? Tests are arbitrary code and can do anything that any other program can do, including starting subprocesses. Just be sure to terminate them once the test is finished, even if it fails.