What should I do with my first test?

[danielmoessner]

I've got the following test with pact:

import { ProductsService } from "../../src/services/products";
import { like } from "@pact-foundation/pact/src/dsl/matchers";
import { pactWith } from "jest-pact";

pactWith({ consumer: "frontend", provider: "products" }, (provider) => {
  let client;

  beforeEach(() => {
    client = new ProductsService(provider.mockService.baseUrl);
  });

  // this is the response you expect from your Provider
  const EXPECTED_BODY = [
    {
      vertical_name: "Phones",
    },
  ];

  describe("a call to get list of verticals", () => {
    beforeEach(() =>
      provider.addInteraction({
        // The 'state' field specifies a "Provider State"
        state: "i have a list of verticals",
        uponReceiving: "a request for verticals",
        withRequest: {
          method: "GET",
          path: "/verticals/",
        },
        willRespondWith: {
          status: 200,
          headers: { "Content-Type": "application/json" },
          body: like(EXPECTED_BODY),
        },
      }),
    );

    // (X) More tests here?
    it("returns a list of verticals", () => {
      client.getVerticals().then((verticals) => {
        expect(verticals).toEqual(EXPECTED_BODY);
      });
    });
  });
});

I'm sitting here wondering, isn't that test alone completely useless? I mean I tell pact what I expect as a response and voila I get exactly that. I copied that example from pact-jest and changed it a bit.

Do I have to add more tests in (X), so that my frontend will actually get tested? I'm using vue3, so for example would it be more useful to check that my view component mounts and renders the verticals? And is that how pact is intended to be used on the consumer side?

[TimothyJones]

If you just write consumer tests, you will be marking your own exam. The key value from pact is confirming that the consumer and the provider speak the same language. This means you should use the contract that your consumer tests generate to validate your provider.

You definitely don’t need to confirm that your front end components are rendered - pact is for your API layer.

I would recommend reading the “how pact works” documentation.

[danielmoessner]

Thanks for your answer. I understand the part of testing the provider. In that sense pact helps with consumer driven contracts tests. And following that the code above is not useless.

However, why does pact give me a mock server? If, as you said, I should not use it for frontend components. So the code after (X) is useless? As pact generates a contract file regardless.

[TimothyJones]

Pact only generates a contract file if the test is successful. The mock server is used to assert that the request you sent from your API layer is what you expected in your test setup, and to send the response that you are expecting from the provider. It mocks the provider so that you can do contract testing without needing to do integration testing.

This process is explained in detail here

[mefellows]

Do I have to add more tests in (X), so that my frontend will actually get tested? I'm using vue3, so for example would it be more useful to check that my view component mounts and renders the verticals? And is that how pact is intended to be used on the consumer side?

The way I like to think about writing a Pact test, is that I'm going to write a unit test of my API client. It just so happens, that by using Pact it will capture a contract I can use to later verify that the mocks were correct. i.e. the mocks are validated.

So, asserting that my API client received an HTTP 200 is not very useful (because Pact will do that for you). What is important to check, is that your API client did the right thing with the response.

It's common in JS to simply pass the JSON blob that came back from the API client. If that's the case, then a Pact test won't need much else.

It's also common to convert the JSON into a domain model. In your case ProductsService might return a Product or an error. You can check the correct type was returned, and importantly, that the type has the properties you'd expect.

[danielmoessner]

Ah I see, that is really interesting. I've never thought about creating a domain model because I just pass the JSON. But that would be an entire step within getting the response and then returning data.

In that sense I'm writing integration tests in my frontend (consumer). And as you said it just so happens that these integrations tests are converted into contract tests for the producer side, by pact. Did I get that right?

--
I would take the definition of integration tests from martin fowler, that within microservice architecture it tests the http client (https://martinfowler.com/articles/microservice-testing/#testing-integration-diagram).

[mefellows]

Spot on.

I would take the definition of integration tests from martin fowler, that within microservice architecture it tests the http client (https://martinfowler.com/articles/microservice-testing/#testing-integration-diagram).

Yes, I would say that contract testing is a type of integration test. The individual tests on each side of the contract might be considered a unit/component/other test, but collectively are "integration tests" IMO.

[bethesque]

Or "tests for an integration point" 😉