Closed syJSdev closed 1 year ago
I used this workaround
const req = getMockReq({
get: () => 'x-header-name-response',
})
Hello, thanks for raising an issue.
This seems to be a similar issue to #53 where the mocks don't actually do anything useful in v1.x
, this was originally intentional to keep everything simple.
This appears to be catching people out more now, I'm currently working through expanding the test coverage and then looking to add some default behaviour for the mock functions in a v2.x
where possible.
For now, I would recommend @obar-zik's suggestion of providing your own mock implementation to do what you expect.
Hi, Your library is very useful because its interface is very clear for me. But this work seems to be stopped sadly. Would you like some help?
Hello @konabe,
Thank you for the positive feedback.
The work has mostly stopped on this library now other than resolving any major bugs or fixing outdated packages etc.
There two main reasons for this:
The library more popular now than I expected, out of all of the daily users, this individual issue does not keep getting mentioned, so I am working off the assumption that the majority of users are happy with the implementation/feature set.
I did spend some time on this issue. The main pain points I kept hitting were; how to provide a 'plug-in' approach, so that a new major version does not break every test that has been written to date, but the most significant issue, implementing this feature seems like the opening of the floodgates on an awful lot of work and the introduction of loads of quirks which you don't want from a testing library.
For example, to solve this specific issue it sounds simple, but we'd have to check for any quirks/logic in the get
and header
functions and implement those also, otherwise it would be an incomplete implementation that would not provide confidence when under test and may even result in tests failing/passing incorrectly.
Then you would end up with a library that has a true-ish implementing of two functions mentioned in this issue, but every other function does not, unless they are also all implemented with the exact same logic as express, which would pretty much end up with a duplication of express. I don't think it would provide the confidence people have become accustomed to with the current implementation. As I can see an endless supply of issues where 'mocked function x returns a slight variation on what it should'. Picked at random, req.originalUrl, even something that sounds simple has a load of edge cases that would have to be considered and implemented in a mocked version.
If this hasn't put you off, then feel free to start thinking about it, but I cannot guarantee any work will get merged in as there just seems like a lot of potential downsides at the moment.
I will close these two issues for now, but can re-open if a new solution is developed.
Thanks, Adam
@aboyce Thank you for your response. I understand your idea to keep confidence of testing. Thank you for your honest work :)
To mock heder:
const req = getMockReq({
header: jest.fn((key: string): string => {
const headerVal: { [key: string]: string } = {
'X-header': "123",
};
return headerVal[key];
}),
});
const xHeader = req.get('x-header') // xHeader should be 123
Expected Behavior
Current
req.get('x-header-name')
returns undefined.req.header('x-header-name')
returns undefined.Reference
Version: 1.4.5