DEV Community: Ashley Davis

Streamlined Contract Testing in Node.js: A Simple and Achievable Approach

Ashley Davis — Wed, 27 Nov 2024 16:01:50 +0000

Do you want the benefits of contract testing with much less effort? Are you convinced of the benefits of contract testing but think it’s just too difficult to roll out across your organization?

You might worry that implementing Pact in your organization requires challenging changes to culture and process.

In this article, I’ll show you a drastically simplified approach to contract testing that a single developer can bring online. You'll get many of the benefits of contract testing for much less work. You'll build a platform that will help convince your team of how much contract testing can help prevent problems going out to production.

If you've ever tried to read the Pact documentation, you might think contract testing is a complicated team-based affair that requires new infrastructure. Let me show you that it doesn’t have to be this way.

Pre-requisites

The example code for this article is available on GitHub.

You can clone the code repository using Git or download the zip file and unpack it.

You’ll need Node.js installed to run the example code. The code repository contains three working examples that we’ll go through in turn. Follow along and try out each example for yourself.

Testing a REST API with a Simplified Contract

For our first example of simplified contract testing, let’s run some tests against an existing REST API. We’ll use the JSON Placeholder REST API.

JSON Placeholder is a fake REST API that includes endpoints for creating, updating, reading, and deleting “blog posts”. In Figure 1, you can see the JSON response for getting all blog posts. Load this URL in your web browser to see it for yourself:

Figure 1: The JSON response from JSON Placeholder getting all blog posts, viewed in Chrome.

We'll use the Jest testing framework to run our contract tests. The Axios code library will make HTTP requests to the JSON Placeholder REST API, then we’ll check that the responses conform to a contract defined in a JSON schema. The setup for our first example is illustrated in Figure 2:

Figure 2: Using Jest to make HTTP requests and checking the responses against a JSON schema.

To try out the contract tests, you’ll need a local copy of the code repository and Node.js installed. Change into the rest-api subdirectory for the first example project:

cd simplified-contract-testing/rest-api

Then install project dependencies:

npm install

Now run the tests:

npm test

After a few moments, you should see the output from a handful of successful tests.

Now let’s see how the code works. Listing 1 shows a pared-down version of the YAML test spec that makes a HTTP request to the /post endpoint and checks the response against the GetPostsResponse schema. The code repo has an expanded version that contains tests for multiple HTTP endpoints.

schema:
  definitions:
    # Schema for a blog post:
    Post:
      title: Represents a blog post.
      type: object
      required:
        - userId
        - id
        - title
        - body
      properties:
        userId:
          type: number
        id:
          type: number
        title:
          type: string
        body:
          type: string
    # Schema for the REST API response:
    GetPostsResponse:
      title: GET /post response
      type: array
      items:
        # Reference to the Post schema.
        $ref: "#/schema/definitions/Post"
# List of tests specs.
specs:
  # Tests the REST API that gets the list of blog posts.
  - title: Gets all blog posts
    description: Gets all blog posts from the REST API.
    method: get
    url: /posts
    expected:
      status: 200
      headers:
        Content-Type: application/json; charset=utf-8
      body:
        # Reference to the schema for the REST API response.
        $ref: "#/schema/definitions/GetPostsResponse"

Listing 1: A Test Spec That Makes an HTTP Request to the `/posts` Endpoint

How do we convert the test spec to a series of automated tests? For that, we'll use Jest’s test.each function. We can use a very cool technique to generate automated tests from our data.

In this case, we generate tests from our test spec loaded from the YAML file. You can see in Listing 2 that the code required to achieve this is minimal and not complicated. Listing 2 is slightly abbreviated, but not by much if you compare it to the complete code file.

const axios = require("axios");
const yaml = require("yaml");
const fs = require("fs");
const { resolveRefs } = require("./lib/resolver");

const { matchers } = require("jest-json-schema");
expect.extend(matchers);

// The REST API we are testing:
const baseURL = `https://jsonplaceholder.typicode.com`;

describe("Contract tests", () => {
  // Loads the test spec:
  const testSpec = resolveRefs(
    yaml.parse(fs.readFileSync(`${__dirname}/test-spec.yaml`, "utf-8"))
  );

  // Generates a test for each contract test in the spec:
  test.each(testSpec.specs)(`$title`, async (spec) => {
    // Makes the HTTP request:
    const response = await axios({
      method: spec.method,
      url: spec.url,
      baseURL,
      data: spec.body,
      validateStatus: () => true, // All status codes are ok.
    });

    // Matches headers:
    if (spec.expected.headers) {
      for ([headerName, expectedValue] of Object.entries(
        spec.expected.headers
      )) {
        const actualValue = response.headers[headerName.toLowerCase()];
        expect(actualValue).toEqual(expectedValue);
      }
    }

    // Matches response body against the expected schema:
    if (spec.expected.body) {
      expect(response.data).toMatchSchema(spec.expected.body);
    }
  });
});

Listing 2: Generating a Series of Jest Tests from Our Data

We have already seen how simple it can be to make data-driven contract tests against an existing REST API. Now let’s run our contract tests against a more realistic REST API backed by a database.

Mocking Your Database for Fast Contract Tests

To try out this second example for yourself, change into the mocked-mongodb subdirectory, install dependencies, and then run the tests:

cd simplified-contract-testing/mocked-mongodb
npm install
npm test

The problem with testing against real infrastructure (like a real database) is that it makes our automated tests run very slowly. We can speed this up massively by mocking our database. By that, I mean replacing the real database with a fake version we can load up with pre-canned data fixtures to run our automated tests against. So while the real version of the service is configured to use a real database, the version we load for automated testing is configured to use the fake database instead. If you are interested, you can see the full code for the REST API in the code repo.

You can see how this looks in Figure 3. Now we are running a REST API locally, and we have it talking to a mock database where we can control the data fixtures on a test-by-test basis:

Figure 3: Mocking the database and controlling data fixtures on a test-by-test basis.

It turns out to be incredibly easy to mock whole modules when using Jest. Any file we place in the __mocks__ subdirectory can replace a real code module while automated tests run. So we place the file mongodb.js in the __mocks__ subdirectory, and Jest automatically replaces require(“mongodb”) with our mock version of the code. You can see our mock version of MongoDB in Listing 3. Note how it exports the function __setData__, which we can call from our tests to control the data fixture loaded for each test.

//
// A mock version of the MongoDB library.
//

let data = {}; // Data fixtures are plugged in here.

// --snip--

class MongoCollection {
  constructor(collectionName) {
    this.collectionName = collectionName;
  }

  async findOne({ _id }) {
    const collectionData = data[this.collectionName] || [];
    return collectionData.find((el) => el._id.__value === _id.__value);
  }

  find() {
    // A mock version of Mongodb's find function.
    return {
      async toArray() {
        // Returns the data fixture:
        return data[this.collectionName] || [];
      },
    };
  }

  async insertOne() {
    return {
      insertedId: new ObjectId("newly-inserted"),
    };
  }
}

class MongoDatabase {
  collection(collectionName) {
    return new MongoCollection(collectionName);
  }
}

class MongoClient {
  async connect() {}

  db() {
    return new MongoDatabase();
  }
}

// Allows automated tests to set data fixtures.
function __setData__(_data) {
  data = _data;
}

module.exports = {
  MongoClient,
  ObjectId,
  __setData__,
};

Listing 3: The Mock Version of MongoDB

Now that we have a mock database and the ability to load data fixtures, we must give our test spec the ability to control which data fixture is loaded for each test. You can see a snippet of the updated test spec in Listing 3. Note the new fixture field that, in this case, specifies that this test should load the data fixture named many-posts.

- title: Gets all blog posts
    description: Gets all blog posts from the REST API.
    # Specifies the data fixture to load before running the test:
    fixture: many-posts
    method: get
    url: /posts
    expected:
        status: 200
        headers:
            Content-Type: application/json; charset=utf-8
        body:
            $ref: "#/schema/definitions/GetPostsResponse"

Listing 4: A Test That Loads the Data Fixture `many-posts`

What we are missing now is the code that loads the data fixture for each test, which you can see in Listing 5 — or check out the full version in the code repo. We are now running a local REST API so you can see how we start the web server before each test. Also note the call to loadFixture at the start of each test, which loads the data
fixture requested by the test.

// --snip--

describe("Contract tests", () => {
  // Loads the test spec:
  const testSpec = resolveRefs(
    yaml.parse(fs.readFileSync(`${__dirname}/test-spec.yaml`, "utf-8"))
  );

  // --snip--

  beforeEach(async () => {
    // Starts the web server on a random port before each test:
    await startServer();
  });

  afterEach(async () => {
    await closeServer();
  });

  test.each(testSpec.specs)(`$title`, async (spec) => {
    if (spec.fixture) {
      // Loads a named database fixture into the mock MongoDB for each test:
      loadFixture(spec.fixture);
    } else {
      clearFixture();
    }

    // Makes the HTTP request:
    const response = await axios({
      method: spec.method,
      url: spec.url,
      baseURL,
      data: spec.body,
      validateStatus: () => true,
    });

    // Matches status:
    if (spec.expected.status) {
      expect(response.status).toEqual(spec.expected.status);
    }

    // Matches headers:
    if (spec.expected.headers) {
      for ([headerName, expectedValue] of Object.entries(
        spec.expected.headers
      )) {
        const actualValue = response.headers[headerName.toLowerCase()];
        expect(actualValue).toEqual(expectedValue);
      }
    }

    // Matches response body against the expected schema:
    if (spec.expected.body) {
      expect(response.data).toMatchSchema(spec.expected.body);
    }
  });
});

Listing 5: Starting the Web Server and Loading Data Fixtures Before Each Test

Running contract tests against a REST API is pretty useful, but we must often also work with services that communicate via asynchronous message queues. For this third and final example, we will extend our REST API so that it can send and receive messages through a RabbitMQ instance. Try out the tests for yourself:

cd simplified-contract-testing/mocked-rabbit
npm install
npm test

Mocking Your Message Queue for Fast, Asynchronous Contract Tests

Please note that we are mocking RabbitMQ in this example, but in principle, this technique can work for any asynchronous messaging system (such as Kafka or SQS).

Let's mock the module amqplib (essentially RabbitMQ), so that we can:

Directly invoke asynchronous message handlers.
Retrieve asynchronous published messages.

You can see how this looks in Figure 4. Our Jest tests are now acting through our mock version of RabbitMQ to interact with our REST API:

Figure 4: Using a mock version of RabbitMQ to interact with our REST API during automated testing.

Our mock version of AMQPlib, which we use to replace RabbitMQ, is similar to our mock version of MongoDB. We add the file amqplib.js to the __mocks__ subdirectory and Jest automatically replaces require(“amqplib”) with the mock version you see in Listing 6. Published messages are saved in the __published__ object, and the mock AMQPlib also tracks message handlers in the __consume__ object.

const crypto = require("crypto");

// Allows the contract tests to check messages that were published to the message queue:
const __published__ = {};

// Allows the contract tests to invoke message handlers:
const __consume__ = {};

const __queue_bindings__ = {};

const mockChannel = {
  async assertExchange() {},

  async assertQueue() {
    return {
      queue: crypto.randomBytes(5).toString("hex"),
    };
  },

  async bindQueue(queueName, exchangeName) {
    __queue_bindings__[exchangeName] = queueName;
  },

  // Publishes a message to a mock queue.
  async publish(exchange, routingKey, content) {
    __published__[exchange] = JSON.parse(content.toString());
  },

  // Binds an event handler to a message queue.
  async consume(queue, handler) {
    __consume__[queue] = handler;
  },

  ack() {},
};

const mockConnection = {
  async createChannel() {
    return mockChannel;
  },
};

async function connect() {
  return mockConnection;
}

module.exports = {
  connect,
  __published__,
  __consume__,
  __queue_bindings__,
};

Listing 6: The Mock Version of AMQPlib Used to Replace RabbitMQ

With RabbitMQ mocked, our Jest tests can now invoke asynchronous message handlers directly in our code and then check any asynchronous responses that are subsequently published. Now that we can trigger HTTP requests or asynchronous messages from our tests, we need to update our test spec to specify the required type for each test. You can see an example in Listing 7. Note how the type field specifies rabbit, and the exchange field selects the RabbitMQ “exchange” we are using to trigger the asynchronous message handler we are trying to test.

At this point, we are not just checking “immediate responses” from HTTP requests, we now must also be able to check for asynchronous messages and compare them against the expected JSON schema. Note the asyncResponse section of Listing 7 and how it defines the schema for a message that is expected to be published on the payment-processed exchange.

- title: Processes a payment on new user
    description: Processes a payment on adding a new user.
    fixture: many-posts
    # The "trigger" that invokes the code to be tested:
    type: rabbit
    exchange: new-user
    body:
        userId: 1
        name: John Doe
    expected:
        # Expectations for the asynchronous response:
        asyncResponse:
            type: rabbit
            exchange: payment-processed
            body:
                $ref: "#/schema/definitions/UserPaymentProcessedMessage"

Listing 7: A Test Triggers an Async Message Handler

We have extended our contract testing system to be even more flexible:

We can trigger HTTP requests or asynchronous message handlers.
We can match HTTP responses and asynchronous responses against a schema.

This means we can test the following combinations:

Trigger an HTTP request and check that its immediate response matches expectations.
Trigger an HTTP request and check that it results in publishing an asynchronous message that matches expectations.
Trigger an async message handler and check that it results in publishing an asynchronous message that matches expectations.

You can find examples of all these combinations in the expanded test spec in the code repo.

The code that generates our contract testing suite is getting more complex, as you can see in Listing 8. Still, it’s not bad considering the number of tests and the different testing combinations that we can achieve with this relatively small piece of code. See the full code that generates the contract tests in the code repo.

// --snip--

// The "http" trigger.
async function http(spec) {
  return await axios({
    method: spec.method,
    url: spec.url,
    baseURL,
    data: spec.body,
    validateStatus: () => true,
  });
}

// The "rabbit" trigger.
async function rabbit(spec) {
  const queue = amqplib.__queue_bindings__[spec.exchange];
  if (!queue) {
    throw new Error(`No queue is bound for exchange '${spec.exchange}'`);
  }

  // Uses the mock "amqplib" to invoke the message handler:
  const consumeHandler = amqplib.__consume__[queue];
  if (!consumeHandler) {
    throw new Error(
      `No consumer found for queue '${queue}' bound to exchange '${spec.exchange}'`
    );
  }

  consumeHandler({ content: Buffer.from(JSON.stringify(spec.body)) });
}

const triggers = {
  http,
  rabbit,
};

test.each(testSpec.specs)(`$title`, async (spec) => {
  // --snip--

  // Triggers the code to be tested.
  const trigger = triggers[spec.type];
  const immediateResponse = await trigger(spec);

  // Matches the immediate response against the expected schema.
  if (spec.expected.immediateResponse) {
    if (spec.expected.immediateResponse.status) {
      expect(immediateResponse.status).toEqual(
        spec.expected.immediateResponse.status
      );
    }

    if (spec.expected.immediateResponse.headers) {
      for ([headerName, expectedValue] of Object.entries(
        spec.expected.immediateResponse.headers
      )) {
        const actualValue = immediateResponse.headers[headerName.toLowerCase()];
        expect(actualValue).toEqual(expectedValue);
      }
    }

    if (spec.expected.immediateResponse.body) {
      expect(immediateResponse.data).toMatchSchema(
        spec.expected.immediateResponse.body
      );
    }
  }

  // Matches the async response against the expected schema.
  if (spec.expected.asyncResponse) {
    const expectedResponse = spec.expected.asyncResponse;
    if (!expectedResponse.exchange) {
      throw new Error(
        `An exchange is required for async responses on spec '${spec.title}'`
      );
    }
    const actualAsyncResponsePayload =
      amqplib.__published__[expectedResponse.exchange];
    if (!actualAsyncResponsePayload) {
      throw new Error(
        `Expected async response to be published on exchange '${expectedResponse.exchange}'.`
      );
    }

    if (expectedResponse.body) {
      expect(actualAsyncResponsePayload).toMatchSchema(expectedResponse.body);
    }
  }
});

Listing 8: Our Contract Testing Code Now Handles HTTP and Asynchronous Requests and Responses

Our adventure in contract testing isn’t complete until we fully automate our tests.

Adding Contract Tests to Your CI/CD Pipeline

We can automate our tests in any CI/CD provider, as long as we can clone our code, install Node.js, and run the following commands in our project:

npm ci
npm test

Given that our external dependencies are mocked (MongoDB and RabbitMQ in these examples), that’s all that we need to get our simplified contract tests running in our CI/CD pipeline.

Listing 9 shows a CI pipeline for GitHub Actions. You can see the full, multi-project version in the code repo.

name: Automated contract tests

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  contract-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v3 # Installs Node.js.
        with:
          node-version: 20

      - run: npm ci # Installs project dependencies.
      - run: npm test # Runs the automated contract tests.

Listing 9: The GitHub Actions Workflow Runs Simplified Contract Tests for a Project

Back in the beginning of this article, I showed how we can run contract tests against an existing REST API. In the same way, we can run our contract tests against any REST API or service that we can access.

Because we control the code making the HTTP request, we can augment the code to include authentication details for the production deployment of our REST API and then run the contract tests against it. If you are contract testing against a production service via asynchronous messaging, then you'll need access (e.g., via an SSH tunnel or Kubernetes port forwarding) to your message queue.

Obviously, we must be very careful if we run contract tests against a production system, especially when tests can make changes to that system. In the full version of my example, you may have noticed that one of the tests makes an HTTP POST request to create a blog post in the REST API. Tests like this are probably best run against a QA or staging deployment, but if you really do want to run them against production, you might want a test account to easily flush out after running tests.

Bringing It Together: How I Applied Contract Testing

In my team, we used the simplified approach to contract testing covered in this post without making the team adopt any arduous processes. We integrated it into our usual automated testing process (in this example, running npm test in our CI pipeline), and we didn’t need any new infrastructure (like a contract broker) to bring all this together.

Mocking, while not specifically related to contract testing, proved essential in making it convenient and fast to run these tests. Contract testing is more on the level of integration testing in terms of how much code it can cover for the least amount of effort.

But because we mock certain external services (like the database and message queue), our contract tests can be much closer to unit tests in terms of performance. This makes it easy and fast to run our contract tests locally for frequent feedback while we make code changes to a REST API or microservice.

Wrapping Up

In this article, we've shown you that contract testing in Node.js can be as simple as defining a JSON schema and then using your favorite testing framework to check responses from REST APIs and asynchronous messaging.

Using this simplified approach to contract testing, you can get started very quickly and gain practical results that will help convince your team that contract testing is worthwhile.

Happy testing!

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.

Effective Testing in JavaScript

Ashley Davis — Thu, 23 May 2024 12:00:00 +0000

The single most important rule of testing is to do it.

Kernighan & Pike, The Practice of Programming, 1999

Despite constantly changing technologies and the needs of customers, some wisdom seems eternal. Programmers need to test their code.

But thorough testing takes time. When we do it well, everything works, and a massive testing effort feels like a waste. However, when we do it badly, our code is often broken, and we wish that we had done better testing.

I have some good news for you. Testing doesn’t have to be arduous and we can still get good results. Part of it comes down to our attitude: come at it the right way and it will be much easier.

Another part of it is the techniques we use. In this blog post, I’ll show you some testing techniques (with code examples on GitHub) that can deliver much more bang for your buck.

Why Test?

We test our code to ensure that it works. I know, it seems obvious.

But that’s not enough. To be more effective, we must catch bugs early. The earlier we find them, the cheaper they are to fix. When a bug goes out to production and is found by a customer, then it’s a whole lot more expensive to get it reported, reproduced, and handed off to a developer — and they probably then have to spend time loading the mental context they need to find and fix it.

Testing enables refactoring. Evolution allows good design to emerge naturally through repeated refactoring and simplification, but we can’t do that safely without testing.

The best reason for testing is that it allows us to see things from our customer's perspective. This is one of the most important perspectives we can take, helping us see the bigger picture around our code.

My Fundamental Rule of Development

I don’t have many hard and fast rules, but this one is inviolable:

Keep your code working.

This is a mantra I repeat to myself while coding. Coding becomes a game where I take code through a series of iterations, going from working code to working code, then testing and making it work again. And so it goes. The sum total is a large amount of working and reliable code.

I’ve been writing code for a long time. In the early years of my career, I was arrogant enough to assume that my code would come out working and was often surprised when it didn’t.

In the later part of my career, I’ve turned that assumption around: now, I think that most code comes out broken. Going further, I believe that the natural state of code is being broken. There are so many more ways code can be broken than for it to accidentally work.

When Should We Test Our Code?

We should test our code early and often.

Testing frequently means problems don’t build up and snowball into bigger problems. It creates the fast feedback loop we need to stay on track and be agile.

Testing early means we don’t delay the discovery of problems. We should aim for a small distance between coding and testing. The less we have to test, the easier it is to test, and the less chance that unnoticed bugs can creep into our code.

We should make frequent commits to our code repository. I like to think of this as putting working code in the bank. If, at any point, I run into a mess, I can reset my working code to the last commit — which I know is working, because I only commit working code. I can abandon my work in progress at any time without losing much effort. Aiming for small commits means I never have much work to lose.

Manual Testing vs. Automated Testing

I’ve been a developer for over 26 years, and I’ve probably spent more time doing manual testing than automated testing. So I know for sure that there’s nothing inherently wrong with manual testing and I still often do it, even when I do later follow it up with automated testing.

Manual testing can get us a long way. Except that repeating the same manual tests over and over again is tedious and time-consuming, not to mention prone to mistakes and laziness (you never forget to test right?).

When we write an automated test for a feature or a piece of code, we get all future testing of that feature for free. For this reason, automated testing can be worthwhile, but it will only pay for itself over the long haul.

Automated testing allows us to scale up our testing. A single developer has the potential to conduct vastly more tests than they could ever achieve manually. Of course, this assumes that a massive effort has already been expended to build the automated tests in the first place.

Because automated testing is automatic, it means we won’t be tempted to skip or forget testing. It also enables more frequent testing, which, as discussed, is crucial to getting fast feedback and keeping our code working.

Running a suite of automated tests gives us immediate confidence in our code, which is priceless and hard to achieve with manual testing.

Even after espousing the benefits of automated testing, I can assuredly say that not all code is worth the effort.

Not All Code Has Equal Value

The stark fact is that not all code is equally important. Some code will be used once or infrequently, some will be thrown out, and some will be drastically changed from its original form.

On the other hand, some code will be very important, some will be updated and evolved constantly, some will need to be very reliable, and some will need to be very secure.

At the outset of writing any piece of code, it’s extremely difficult to know if that code is worth the effort of automated tests. If you invest in automated tests (or automating anything) when the effort isn’t warranted, you will waste precious time that might be better spent elsewhere.

Using test-driven development (TDD) or otherwise aiming for 100% test coverage is a huge sacrifice in productivity because it treats all code as equally valuable. There is a diminishing return on investment for your effort. The more we push our testing to the extreme, the less value it yields.

The Single Best Way to Improve at Testing

I used TDD for many years before I realized I was spending way too much effort trying to test all the code, including the code that didn’t require that level of effort. Sometimes I still use TDD, but only for the most important code. I enjoy practicing TDD and it has helped build my testing discipline. I learned to create code that’s easier to test, but I don’t often do it now. It’s far too expensive for the resource-starved startups I’ve bootstrapped in recent years.

But TDD gave me what was probably my single most important lesson ever in coding and testing:

Think about testing before coding.

Any effort we make to visualize testing before coding results in code that is easier to test. Code that is easier to test is easier to keep working. Of course, this has nothing to do with TDD and we can easily fit thinking into our normal development process without TDD or even without any automated testing.

Effective JavaScript Testing Techniques

Following are some techniques for good testing with less effort.

You can find the set of example projects here.

Technique	Usage	Description
Output testing	Manual or automated	Comparing previous output to the latest output to see what has changed.
Visual testing	Manual or automated	Comparing before and after screenshots to see what has changed.
Manual testing, followed by automated testing	Automated	Testing manually to confirm the code works. Followed by automated tests.
Integration testing REST APIs	Automated	Applying automated testing to whole services.
Frontend testing with Playwright	Automated	Testing frontends using Playwright.

Output Testing

Like golden testing, output testing checks the output against the last known working version. We can easily use a Diff tool (e.g., git diff) to view the differences.

This is great for data pipelines (we diff the data that is output), but we can also use it to test behavior by including a log of important events in the output.

Output testing can be used manually (we can visually check the differences) or automatically (by having our CI pipeline fail if there are differences).

Output testing is simple to start using. It supports refactoring (any refactor should cause no difference in the output).

Here's some example code.

Visual Testing

Like snapshot testing, visual testing compares the visual output (e.g., a screenshot) of our application against the last known working version.

This is more difficult than output testing, but it works well for checking that changes in our code make no (or little) difference to its visual output.

My code example uses Puppeteer to screenshot a web page and then ImageMagick to compare the screenshots. ImageMagick gives a metric indicating the amount of differences. This allows us to set a threshold and tune the system to tolerate small differences to a level that we can live with.

Visual testing can be used manually (we scan the differences with our eyes) or automatically (failing our CI pipeline when ImageMagic’s difference metric is above a certain threshold).

With a visual testing system in place, we can quickly scale it across 100s or 1,000s of web pages. It can take some time to run a big test suite, but it’s the fastest way to search for visual problems across many web pages.

Here's the example code.

Manual Testing, then Automated Testing

We can get more effective results from traditional automated testing if we do manual testing followed up by automated testing.

This means we can go through multiple rounds of evolution and refactoring supported by manual testing (or output testing, as mentioned previously) before we commit to automated testing. This can save a lot of time because it’s very time-consuming to have to keep automated tests working while we are creating and evolving new code.

Creating automated tests becomes easy as well. We can use the captured output or code behavior for our automated tests. Fitting automated tests to the code (that we already know works) can be much easier than attempting to write tests from scratch.

Saving automated testing until later also allows for an informed decision about whether automated testing is actually necessary in each particular case.

Check out some example code.

Integration Testing REST APIs

The most effective way to test REST APIs is to make HTTP requests against the entire service using a traditional automated testing framework (e.g., Jest).

This is much faster to implement than unit testing and much easier to keep working over time. We get to test more code with a smaller suite of tests.

We can also test other types of services in a similar way (for example, a microservice that accepts inputs from a message queue). In cases like this, we can feed input via messages instead of HTTP requests.

See some example code.

Frontend Testing with Playwright

Anyone who has tried to test UI components using traditional automated testing will tell you how painful it can be.

A more effective way of testing UIs is using a frontend testing framework like Playwright. We can do end-to-end testing of our whole system (frontend and backend), or we can completely mock the backend to focus on integration testing the frontend. This kind of testing covers the most ground for the least effort.

See some example code.

Wrapping Up

We all have to test our code. That’s the only way to ensure it’s fit for purpose.

But as we've seen in this post, we don’t have to labor on time-intensive traditional testing methods. There are more effective testing techniques out there that can save us so much time, and we can still have great tests. I encourage you to come up with testing techniques for your situation that need little effort.

The important thing is that we deliver valuable and reliable code to our customers. They don’t care how we build or test it, only that we give them something that works well and delivers the value they need.

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.

DEV Community: Ashley Davis

Streamlined Contract Testing in Node.js: A Simple and Achievable Approach

Pre-requisites

Testing a REST API with a Simplified Contract

Listing 1: A Test Spec That Makes an HTTP Request to the /posts Endpoint

Listing 2: Generating a Series of Jest Tests from Our Data

Mocking Your Database for Fast Contract Tests

Listing 3: The Mock Version of MongoDB

Listing 4: A Test That Loads the Data Fixture many-posts

Listing 5: Starting the Web Server and Loading Data Fixtures Before Each Test

Mocking Your Message Queue for Fast, Asynchronous Contract Tests

Listing 6: The Mock Version of AMQPlib Used to Replace RabbitMQ

Listing 7: A Test Triggers an Async Message Handler

Listing 8: Our Contract Testing Code Now Handles HTTP and Asynchronous Requests and Responses

Adding Contract Tests to Your CI/CD Pipeline

Listing 9: The GitHub Actions Workflow Runs Simplified Contract Tests for a Project

Bringing It Together: How I Applied Contract Testing

Wrapping Up

Effective Testing in JavaScript

Why Test?

My Fundamental Rule of Development

When Should We Test Our Code?

Manual Testing vs. Automated Testing

Not All Code Has Equal Value

The Single Best Way to Improve at Testing

Effective JavaScript Testing Techniques

Output Testing

Visual Testing

Manual Testing, then Automated Testing

Integration Testing REST APIs

Frontend Testing with Playwright

Wrapping Up

Listing 1: A Test Spec That Makes an HTTP Request to the `/posts` Endpoint

Listing 4: A Test That Loads the Data Fixture `many-posts`