I did work in a team that had multiple services in different technologies and there was a push to do consumer-driven contract testing with Pact and it got implemented for Ruby services. At that point the tooling for Elixir was not that great so we didn’t do it in the end, but I think the biggest reason was that it was always a low priority item for us - we did have an extensive set of tests for the API, so I saw little to no value (but significant effort) in adding Pact tests.

Instead of Pact I’d suggest writing unit tests (note that here the unit of the test is a behavior/endpoint, not a module/function) this way:

describe "GET /api/foobars" do
  test "requires authorization" do
    assert %{status: 401, body: body} = get(nil, "/api/foobars")
    assert %{"error" => "Unauthorized"} = body   
  end

  test "returns a list of foobars" do
    assert %{"foobars" => []} = get!(api_key, "/api/foobars")
  end
end

The idea here is to write your tests as if they were written using an external tool (you’ll need to add some helpers for making HTTP requests), but run them inside your normal test suite (mix test) to leverage all the ExUnit goodies and keep them fast.

I certainly would call them unit tests, but then we get to the point of what is the unit of a test? I think the common approach of treating a class, module or a function a unit of a test is not really useful. For me the unit of a test is a single feature/behaviour.

In my books, an integration test is one where multiple independently-deployable services are involved.

I don’t know if you can call these unit tests, I usually refer to these kind of tests as integration tests, as they test the system interactions as a whole, not just isolated parts.