The code is something like, ```it("returns the req...
# pact-js
s
The code is something like,
Copy code
it("returns the requested employee", async () => {
      provider
        .given("I have an empoyee")
        .uponReceiving("a request for getting the employee by name")
        .withRequest({
          method: "GET",
          path: "/api/employees/name/Charles",
          headers: { Accept: "application/json" },
        })
        .willRespondWith({
          status: 200,
          headers: { "content-type": "application/json" },
          body: GET_EMPLOYEE_BY_NAME_EXPECTED_BODY,
        });

      return provider.executeTest(async (mockserver) => {
        const employeeService = new EmployeeService(mockserver.url);
        const response = await employeeService.getEmployeeByName("John");
        expect(await response.headers["content-type"]).toEqual(
          "application/json"
        );
        expect(await response.data).toEqual(GET_EMPLOYEE_BY_NAME_EXPECTED_BODY);
        expect(await response.status).toEqual(200);
      });
    });
t
I only see one test in your code. I would check that you’re awaiting the things that need to be awaited appropriately
Oh, ECONNRESET. There are some breaking changes to the connection pool in some recent version of node. You’ll need to make sure you’re not reusing connections between tests, or that your client is correctly handling a connection reset
s
@Timothy Jones Please find the complete file below.
Copy code
import { MatchersV3 } from "@pact-foundation/pact";
import EmployeeService from "../../../src/apis/EmployeeService.js";

describe("Employee Clients Service", () => {
  const GET_EMPLOYEES_EXPECTED_BODY = [
    {
      id: 1,
      name: "Amy",
      surname: "Jakline",
      role: "Software Engineer",
    },
    {
      id: 2,
      name: "Jake",
      surname: "Folker",
      role: "Test Analyst",
    },
    {
      id: 3,
      name: "Charles",
      surname: "Hucker",
      role: "Scrum Master",
    },
    {
      id: 4,
      name: "Terry",
      surname: "Roland",
      role: "Developer",
    },
    {
      id: 5,
      name: "Rosa",
      surname: "Marie",
      role: "Technical Solution Architect",
    },
  ];

  //afterEach(() => provider.verify());

  const GET_EMPLOYEE_BY_NAME_EXPECTED_BODY = [
    { id: 3, name: "Charles", surname: "Hucker", role: "Scrum Master" },
  ];

  describe("GET All Employees", () => {
    it("returns all employees", async () => {
      provider
        .given("I have a list of empoyees")
        .uponReceiving("a request for getting all employees")
        .withRequest({
          method: "GET",
          path: "/api/employees",
          headers: { Accept: "application/json" },
        })
        .willRespondWith({
          status: 200,
          headers: { "content-type": "application/json" },
          body: GET_EMPLOYEES_EXPECTED_BODY,
        });

      return provider.executeTest(async (mockserver) => {
        const employeeService = new EmployeeService(mockserver.url);
        const response = await employeeService.getEmployees();
        console.log("response1: " + response);
        expect(await response.headers["content-type"]).toEqual(
          "application/json"
        );
        expect(await response.data).toEqual(GET_EMPLOYEES_EXPECTED_BODY);
        expect(await response.status).toEqual(200);
      });
    });
  });

  describe("GET Employee By Name", () => {
    it("returns the requested employee", async () => {
      provider
        .given("I have an empoyee")
        .uponReceiving("a request for getting the employee by name")
        .withRequest({
          method: "GET",
          path: "/api/employees/name/Charles",
          headers: { Accept: "application/json" },
        })
        .willRespondWith({
          status: 200,
          headers: { "content-type": "application/json" },
          body: GET_EMPLOYEE_BY_NAME_EXPECTED_BODY,
        });

      return provider.executeTest(async (mockserver) => {
        const employeeService = new EmployeeService(mockserver.url);
        const response = await employeeService.getEmployeeByName("Charles");
        console.log("response2: " + response);
        expect(await response.headers["content-type"]).toEqual(
          "application/json"
        );
        expect(await response.data).toEqual(GET_EMPLOYEE_BY_NAME_EXPECTED_BODY);
        expect(await response.status).toEqual(200);
      });
    });
  });
});
t
Yeah, your test is fine. It’s the connection pool thing, not a pact issue (but you’re more likely to see it with pact, because it starts and stops the server in between each test)
It is actually detecting a mistake with the way your client uses the connection pool
s
ok
Copy code
import * as path from 'path';
import { PactV3 } from "@pact-foundation/pact";

global.port = 8081
global.provider = new PactV3({
  port: global.port,
  log: path.resolve(process.cwd(), "__tests__/contract/logs", "mockserver-integration.log"),
  dir: path.resolve(process.cwd(), "__tests__/contract/pacts"),
  spec: 2,
  logLevel: 'INFO',
  pactfileWriteMode: "overwrite",
  consumer: "Frontend",
  provider: "EmployeeService",
})
t
Also you don’t need to declare your test callback (inside the
it
) as async, but it won’t matter if you do
s
This is how I am setting up
t
I’m on mobile so I can’t link you, but I wrote a bit about this issue for someone else the other day
1
I think it was in an issue on the pact-js repo
1
But you can also find the solution by reading the release notes for node
1
They changed the http connection pool default behaviour
s
Thank you @Timothy Jones
t
I think it might be an improvement to have pact add a header saying the connection should be closed. But also, if it did that then I think this issue would be masked
m
I think it might be an improvement to have pact add a header saying the connection should be closed. But also, if it did that then I think this issue would be masked
that’s a good point. Interesting. My gut feel is that it probably still makes sense for us to add that setting, as it feels more “infrastructure-y” than contract-testing.
t
yeah, I think you’re right. By default it makes sense for the contract tests to just work on the data. It would be cool to have a “flaky” mode, with injected failures / problems for people using the mock server to back part of a black box test or something.
m
It would be cool to have a “flaky” mode, with injected failures / problems for people using the mock server to back part of a black box test or something.
I’m reminded of this post by Tal when at PageUp: https://medium.com/@rotbart/driving-api-client-resiliency-how-to-enforce-postels-law-by-violating-postel-s-law-4fd6ef9da205