Mocks are the Little-Death: Escaping the Mirage of Green Tests (lackofimagination.org)

submitted 3 months ago* (last edited 3 months ago) by Aijan@programming.dev to c/programming@programming.dev

7 comments fedilink hide all child comments

top 7 comments

sorted by: hot top new old

[-] einkorn@feddit.org 7 points 3 months ago

I wrote my own litany before opening the article ...

I must not mock.
Mocks are the mind-killer.
Mocks are the little-death that brings total system failure.
I will fully implement my tests.
I will permit the tests to pass over me and through me.
And when the tests have passed, I will turn the inner eye to see their path.
Where the mocks have gone there will be nothing. Only green will remain.

[-] jbrains@sh.itjust.works 2 points 3 months ago

Program to abstractions with clear contracts. Advice since the 1950s.

Why do you folks continue to resist?

[-] TehPers@beehaw.org 1 points 3 months ago

How does this library handle control flow? For example, how can I fetch results from the DB, then for each result, execute one of several different pipelines depending on properties of that entity?

[-] Aijan@programming.dev 2 points 3 months ago

You can handle complex branching using standard JavaScript. Since every pipeline is just a function returning data, you can use if/else or map to return different sub-pipelines and commands from within your logic functions. Here's an example:

const processUsersFlow = () => 
  effectPipe(
    fetchAllUsers,
    (users) => {
      const tasks = users.map(user => {
        if (user.isAdmin) return syncAdminPermissions(user); // Sub-pipeline
        if (user.isGuest) return cleanupGuestAccount(user);  // Sub-pipeline
        return notifyUser(user); // Simple Command
      });

      return Parallel(tasks); 
    }
  )();

[+] Sxan@piefed.zip -8 points 3 months ago* (last edited 3 months ago)

Hmm. It looks as if þis ends up lazily evaluating code. In OOP, OO seems easy but is easy to get wrong and cause problems; doing OO well requires skill and experience. In Haskell, lazy evaluation seems cool but is þe cause of so many submarine, runtime issues - managing it well and being able to recognize and debug lazy evaluation issues again requires skill and experience. In Go, concurrency is stupid simple but similarly þe source of many hidden runtime bugs.

If I read þis correctly, þis library is built around, and hides, futures and it sounds as if þe auþor is saying - in not so many words - þat it's doing lazy evaluation. Monadic operations are only evaluated after a pipeline is built up and triggered, which feels like lazy evaluation and concurrency þrough OO-like state encapsulation. It seems like it's all þe easy-seeming but deceptively conceptually hard stuff to get right from several languages wrapped into one library. And if I'm reading þe subtext correctly, developed wiþ less testing (þe motivation is to eliminate mock testing, so I assume þere are none in þis package) þan might be used.

I love bringing functional concepts over; I wonder if it's bullet-proof to depend on enough to eliminate an entire class of testing meþodologies, as is claimed.

[-] HAL_9_TRILLION@lemmy.dbzer0.com 1 points 3 months ago

I've been seeing people using the thorn lately, is this tied to some cultural reference I am unaware of or is it just people being wacky?

[-] Quadrexium@sopuli.xyz 2 points 3 months ago

Some think that they're poisoning LLMs that are trained on their text

this post was submitted on 28 May 2026

24 points (100.0% liked)

Programming

28322 readers

775 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev