Example unit tests for verifying outbound HTTP request parameters in a pure functional language

http-request-tests.sil

private anyHostname = builders.randomHostname(10)
private anyToken = builders.randomToken(10)
private anyResourcePath = builders.randomPathName(8) ~ "/" ~ builders.randomPathName(8)
private emptyResponse = "[]"

Test2(Fixture, "Fetching a resource passes the access token in the PRIVATE-TOKEN header", () => {
    token = builders.randomToken(12)
    getMethod = (url, headers) => {
        assert.that(headers, isTableWithKey("PRIVATE-TOKEN"), "The access token header is missing")
        assert.that(get(headers, "PRIVATE-TOKEN", ""), isEqualTo(token), "The access token was incorrect")
        in emptyResponse 
    }

    netClient = netclientFake.create(getMethod)
    gitlabClient = gitlab._acquireClient(anyHostname, token, netClient)
    model = gitlabClient.getResource(anyResourcePath)

    in assert.pass()
})

Test2(Fixture, "Fetching a resource uses the v4 API", () => {
    hostname = "hostname"
    getMethod = (url, headers) => {
        assert.that(url, isStringStarting("https://"~hostname~"/api/v4"), "The base URL is incorrect")
        in emptyResponse 
    }

    netClient = netclientFake.create(getMethod)
    gitlabClient = gitlab._acquireClient(hostname, anyToken, netClient)
    model = gitlabClient.getResource(anyResourcePath)

    in assert.pass()
})

i think if you're going all in on FCIS, then you can probably get rid of the idea of mocks altogether. pure functions can be tested with inputs and outputs.

in this case, you could imagine a pure function called getApiRequestParams or something, that takes some sort of domain object as input and returns a datastructure representing url, headers and so on.

but really this all feels like it's very much in the IO realm, ie not business logic, so maybe it lives outside of the functional core anyway? just keep api-wrangling code in some sort of adapter, it shouldn't have any kind of complex logic, it's just plumbing, and it doesnt need unit tests, just integration tests.

(i hasten to add that the sum total of my experience of writing unit tests in functional languages is no more than, idk, 35 test and like happened two or three times only one of which was actual production code so it may be worth taking me with a pinch of salt)

in this case, you could imagine a pure function called getApiRequestParams or something...

Yeah, I can see how to break the problem down into smaller pure functions but then it feels like the overall design is being warped just to allow testing. Of course Design for Testability generally has this affect but its nicer if you don't have to warp things too much.

Thanks for the feedback, it's good food for thought.