[CI-3342] Pass section to getRecommendationPods #197
Conversation
esezen
changed the title
| it('Should build requestURL with query params when parameters are passed', (done) => { | ||
| const { recommendations } = new ConstructorIO({ | ||
| ...validOptions, | ||
| fetch: async (reqUrl) => ({ ok: true, json: async () => reqUrl }), |
There was a problem hiding this comment.
Thoughts on not overriding fetch here, actually sending a request?
While this is arguably better, closer to what a unit test should be, the rest of the tests all send requests, so I'm wondering if we should stick with that.
But tbh, doens't matter too much.
There was a problem hiding this comment.
I think in this specific case I'm just trying to test that the request url gets built correctly, and not as concerned with the response. I can add an extra test that sends the request with these parameters for coverage
There was a problem hiding this comment.
I think both approaches are fine but let's test the live request like Stanley mentioned. We can either
- Not override fetch and check both the request url and response in this test
- Leave this test as is and create a new test that's using actual fetch and hitting the API
There was a problem hiding this comment.
added the test 👍. I think it's good to have both just to make sure the parameter is getting added to the url as expected, at least while we have this hacky workaround with parameters/network parameters
Pass section to getRecommendationPods through parameters.
To maintain backwards compatibility, parameters will be treated as networkParameters in some cases. This is until all customers migrate to using both parameters.