Added autoHead functionality to get interceptor

[julescmay]

Added autoHead functionality to get requests.

Now, if there's a get interceptor, there will automatically be an equivalent head interceptor. You can control the behaviour by:

• adding autoHead:false to the get interceptor;
• adding a replacement head interceptor

Explanation and examples in the readme.

[julescmay]

Can I clarify something, please? When you install an interceptor, it's intended only to be used once (then deleted). What persist() does is keep the interceptor active even after it has been used. Have I got that right? If so, can you expain the reasoning, please?

[cah4a]

You are correct.

This is for background tasks that may send dozen similar requests: e.g. /status or /friends_online. Useful for integration testing.

[julescmay]

Thnak you. But I meant: can you explain the reason why it would ever not be persistent? Under what circumstances would an endpoint get used once, then disappear? (I can see that you might want to to use onReply to modify an existing response, but that's a very deliberate thing modelling the state of the mocked server)

[julescmay]

I'm asking, becasue I don't think my solution will work e ntirely as-is, ad will need some patching-up :-(

[cah4a]

Tests should specify the order, request/response content, and count every request.

I don't know your case and what scope you are trying to cover, but in major of my test cases I have roughly the next scenario:

• Open projects list
• Ensure that there are N of them
• Ensure data is returned by Interceptor.
• Create a new project
• Ensure that the app is requesting new data
• Ensure that list is updated
• Ensure that there are N + 1 projects
• Ensure data

I'm treating tests rigorously, hehe.

You could always lower expectations to meet your test coverage requirements.

Why it is not inverted? Because of asymmetry in fail cost. Test that fails easily could be fixed with .persist() while you are writing the test. Production bugs due to lack of .noPersist() is much, much expensive.

[julescmay]

I understand. I don't think I'm less rigourous, but I think I have a different perspective. I would expect to be able to test against a (mock) server which behaves as a server should. That is, (absent explicit changes of server state) get should return the same thing every time, and post should return something different every time, (but - in each case - the endpoint would always be there). It seems to me that it's very odd behaviour for an endpoint (any endpoint) to disappear after first use!

Aside: I also think this is such unexpected behaviour that it's worth explaining in detail in the readme. After reading the readme, using the package, and even writing this change, I still wasn't clear what was going on!

I agree that we should know how many times an endpoint is called - you already have the ability to count with onReply() don't you? But, it would not necessarily be an error (just, inefficient) for a unit under test to call the same get endpoint twice.

bugs due to lack of .noPersist() is much, much expensive.

Hmm... What do you have in mind?

Anyway: in this pr: An explcit interceptor respects its own Persist(), but the implicit one 'persists' as long as its parent does. So, given an unpersisted get clause but no corresponding head:

• head head get works;
• head get get exceptions;
• head get head exceptions;

I think that's the closest I can get to what you expect. Have a look (and a play) and see if you agree (and tell me if not).

Longer term, I have another idea which I'd like to explore with you. Shall I open another issue for it?

[julescmay]

< bump >

[julescmay]