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()
})

This example code is an attempt to work out how to write unit tests for outbound requests, e.g. REST calls, sending emails, etc. in a pure functional language. (The language in question is in-house one but not a company secret.)

When you mock service providers in mutable languages like C++, C#, etc. you can record in the mock itself what invocations happened, but in a pure functional language where everything is immutable you can't record anything as that would be a side-effect [1]. Hence what I'm doing instead is to assert the expectations in the mocked functions instead of the tail of the test body. This does mean an assertation failure generates an error which has to bubble right up the stack to the test body and still manifest as an error; if any intervening code catches and discards errors we're screwed.

---

[1] You could write to a file, database, socket, etc. and read that back in the test body but you can't mutate the in-memory data structures, e.g. a dictionary.

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.