Testing Without Mocks: A Pattern Language

I wouldn't recommend mocking http libraries, database calls etc. - that usually leads to madness and impenetrable test setups. I would rather recommend to either use fake implementations (e.g. in-memory DB) or to only integration-test the boundaries of your interaction with the external system (that might or might not be hard to achieve).

But I do like the pattern of wrapping calls to external APIs through a layer that I control - so that, for example, I may just write mailer.sendMessage(message) - and then that mailer interface seems like a good candidate for mocking.

There's an example of that kind of test here: https://github.com/jamesshore/livestream/blob/2020-09-22-end...

Regarding testing different values, I think what you're missing is that you don't just emit an event; you emit an event with data. Typically it's whatever data you're delivering.

  emitter.emit(:sent_the_email, payload)

  assert.equal(delivered, { 'my_expected' => 'data_goes_here' })

CommandLine is the actual production code that writes to stdout and stderr (and reads command-line arguments). CommandLine.createNull() creates an instance of CommandLine that's "turned off" and doesn't actually write to stdout or stderr. CommandLine.trackStderr() returns a reference to an array that is updated whenever something is written to stderr (or not, in the case of a nulled CommandLine).

I'm off to bed, but I'm happy to answer further questions in the morning. For free, even.

I'm not going to write a full working program, but I'll flesh out your example a bit and explain how it works. I'll use JavaScript and the patterns described in the article.

I'm going to say "A" in your example is the VerificationEmailController class. It has a postAsync() method that handles POST requests. When it receives a POST request, it sends an "verify your email" email, then writes the result to a database.

"B" in your example is SendGridClient. It has a sendEmail() method that uses SendGrid to send email. It does it by making an HTTP call to the SendGrid service.

"C" in your example is a EmailVerificationAuditTable. It has a insertEmailSent() method that inserts a "success" or "fail" record into a database table.

"Failing" in your example involves writing an alert to the application log file. It uses ApplicationLog, which has a logEmergency() method that writes a structured log with the "FATAL" log level.

To summarize, we are writing and testing VerificationEmailController. It depends on SendGridClient, EmailVerificationAuditTable, and ApplicationLog.

SendGridClient, EmailVerificationAuditTable, and ApplicationLog use the patterns in the article. Specifically, they're Nullable, they're Infrastructure Wrappers, they have Configurable Responses, and they use Output Tracking.

Got it? Okay, let's write the test. This test is really doing too much, and should be broken out into multiple separate tests, but I'm going to follow the example you provided.

  it("fails cleanly by retrying email service and database service, then logging an alert", async () => {
    // First, we set up the dependencies. This is the Nullables and Configurable Responses patterns.
    const sendGrid = SendGridClient.createNull({ error: "my email error" });
    const auditTable = EmailVerificationAuditTable.createNull({ error: "my database error" });
    const log = ApplicationLog.createNull();

    // Then we track their output. This is the OutputTracker pattern.
    const sendGridTracker = sendGrid.trackSends();
    const auditTableTracker = auditTable.trackInserts();
    const logTracker = log.trackOutput();

    // Then we instantiate the code under test. This uses normal dependency injection.
    const controller = new VerificationEmailController(sendGrid, auditTable, log);

    // Then we call postAsync(). I'm going to provide realistic code, but not explain it, 
    // because it's not relevant to this example. Normally this would be hidden behind a
    // helper function. (See the "Signature Shielding" pattern.)
    const request = HttpRequest.createNull({ body: JSON.stringify({ email: "my_email" }) });
    await controller.postAsync(request);

    // Now we assert that the controller did what it was supposed to.

    // First, we'll assert that we tried to send two emails.
    assert.deepEqual(sendGridTracker.data, [{
      to: "my_email",
      subject: EMAIL_SUBJECT,
      body: EMAIL_BODY,
    }, {
      to: "my_email",
      subject: EMAIL_SUBJECT,
      body: EMAIL_BODY,
    }]);

    // Then we'll assert that we tried to insert two audit log entries.
    assert.deepEqual(auditTableTracker.data, [{
      recipient: "my_email",
      result: EmailVerificationAuditTable.STATUS.EMAIL_FAILED,
      emailError: "my email error",
    }, {
      recipient: "my_email",
      result: EmailVerificationAuditTable.STATUS.EMAIL_FAILED,
      emailError: "my email error",
    }]);

    // And finally, we'll assert that we logged an alert.
    assert.deepEqual(logTracker.data, [{
      alert: "FATAL",
      code: "L668",
      message: "Email verification failure",
      recipient: "my_email",
      sendGridError: "my email error",
      auditLogError: "my database error",
    }]);
  });

Not even remotely true. Why are you under the impression that you aren't in control of what dependencies get created and form your object graph? Either you've got a misapprehension or you've got a terrible DI framework