Testing advice for modules that delegate to other modules

I am building an API client. The structure is something like this:

├── api
│   ├── base.ex
│   ├── categories.ex
│   ├── search.ex
│   └── users.ex
└── api.ex

api.ex is just a bunch of defdelegates to Categories, Search, Users.

I want that developers use the library through the Api module. What would be the better way to write tests? I have now a good coverage for Categories, Search, Users and 0 tests for Api. Since it only delegates, then is there a point to duplicate the tests? Or maybe there is a way to check that delegation is setup correctly? Or since the Api module is intended to be used, then all tests should go there (but then it will get quite huge)?

What do you think?

Seems like your Api module is the higher-level user of those modules so you are likely looking for unit tests of the other modules and integration tests for Api – namely tests that utilise all functionalities covered by Api.

I don’t see a duplication. Just code integration tests and not unit tests that repeat what was already tested in the lower-level modules.

I just don’t see what I can test differently in api. It is a 1 to 1 delegation without anything else.

How I tested the lower level modules:

    test "returns category id", %{bypass: bypass} do
      Bypass.expect(bypass, fn conn ->
        Plug.Conn.resp(conn, 200, "1")
      end)

      assert {:ok, category_id} = Categories.whatever_function(12345)
    end

So I start a fake server with a known response and I execute the http client against it and check the result.

How would then the api.ex test it differenetly for defdelegate whatever_function(param), to: Categories?

Then I misunderstood. I was left with the impression that Api actually does more by using all the lower-level modules. If that’s not true then I don’t think you should duplicate tests indeed, as you yourself said.

1 Like