The old io.pedestal.test/response-for returned a response map with :headers as a String->String map.
In 0.8 this is replaced with io.pedestal.connector.test/response-for. This returns a response map with :headers as a Lowercase-keyword->String map. đź«
This change breaks my tests, which expect to access headers with keys like "Location" and "Content-Type".
(To whom it may concern:)
Is there, or could there be, a built-in way to get back String->String keys, to match
• https://pedestal.io/pedestal/0.8/reference/response-map.html
• the existing response map headers we create from within an interceptor or context-map (which remain String->String),
• people’s existing tests, and
• the ring spec
…and to avoid having to keep a third type of header pattern in mind:
• lowercase string headers for request maps (per ring)
• original-case headers for interceptor response maps (per ring)
• (and now) lowercase keyword headers for test response maps
Put in slightly different words: Could response-for add both types of keys, original-case strings as before and the new lowercase keywords? I can see wanting to add a nice new affordance with the keywords but the string form is cognitively harmonious with other response maps in pedestal.
Thanks for considering it.
(For now I’ve rewritten response-for in my own ns to also have original-cased string keys as I suggest above. It means importing various private vars from connector.test which is not ideal but it beats rewriting my tests and the cognitive dissonance of having to access headers three different ways depending on the context.)
I’ll look into this. Connector.test is supposed to be “least surprises”.
OK thanks! Just to be clear, can the io.pedestal.test ns and fns be used with the new connector api? For some reason I thought it could not. I could have sworn I tried it but maybe not….
No, it's two separate NSes, because its very different how you initialize the services and other factors. Again, with the eye of accretion: keep the existing code (or at least, the existing APIs and behaviors) stable and introduce new NSes that have the improvements you seek. In this case, a big improvement is only relying on io.pedestal.connector (from the pedestal.service module) and NOT io.pedestal.http (from the pedestal.servlet module, with all of its extra servlet-api dependencies).
ok thanks for explaining!
Still, the point was to leave io.pedestal.test API and behavior unchanged, and introduce a "new approach" with io.pedestal.connector.test.
But I'd consider a breaking change for io.pedestal.connector.test w.r.t headers ... it should just pass them through unchanged.
The intent was to make it easier to write tests that asserted headers, but I take the point that information is lost this way.