In a typical imperative application, business logic and side effects are inextricably linked. For example, when you write await db.checkInventory(…), the runtime immediately reaches out to the database. Our Effect System works differently. Instead of performing the action, our functions return a description of the action. When our code needs to check inventory, it doesn’t call the database; it returns a plain object instead, which will be executed later by an interpreter.
  • magic_lobster_party@fedia.io
    7·
    5 days ago

    This only checks that functions are called in the right order. Not that the functions are doing the right thing or if the functions are called with the correct arguments. Quite pointless testing IMO.

    For example, it won’t capture cases where cmdChargeCreditCard returns a payment ID that exists for cmdCompleteOrder to use.

    Set up an in-memory database, or test against a real database. You don’t test side effects by pretending that the side effects are correct.

    • Aijan@programming.devOP
      1·
      5 days ago

      You can still test the functions individually or run the entire flow against a test database, but without an effect system like this, it’s very hard to test business logic in isolation.