Mocks are the Little-Death: Escaping the Mirage of Green Tests

Comments

• jbrains@sh.itjust.works ⁨6⁩ ⁨days⁩ ago

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

  Why do you folks continue to resist?

  source
• TehPers@beehaw.org ⁨6⁩ ⁨days⁩ 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?

  source

  • Aijan@programming.dev ⁨6⁩ ⁨days⁩ 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); 
        }
      )();
    

    source
• Sxan@piefed.zip ⁨6⁩ ⁨days⁩ 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.

  source

  • HAL_9_TRILLION@lemmy.dbzer0.com ⁨6⁩ ⁨days⁩ 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?

    source

    • Quadrexium@sopuli.xyz ⁨6⁩ ⁨days⁩ ago

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

      source
• CombatWombat@feddit.online ⁨6⁩ ⁨days⁩ ago

  I was thinking more la petite mort and less Dune so I expected something much more… enthusiastic about mocking.

  source
• einkorn@feddit.org ⁨6⁩ ⁨days⁩ 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.

  source