3 ms·
I used this strategy when developing a client library for a web socket API. It was hugely helpful. I could just include the string of the response in my tests
by bmh100 6y ago
I used this strategy when developing a client library for a web socket API. It was hugely helpful. I could just include the string of the response in my tests, instead of needing a live server or even a mock server for testing. Tests were much simpler to write and faster to execute.
- danenania 6y agoThis is great until the API response changes and you have to painstakingly update all your string fixtures to match.
- hinkley 6y agoThe mocks have the same fixtures, plus a bunch of plumbing you have to sort out with every major and some minor version number upgrades. You pay a bigger tax on the mocks down the road.
- jschwartzi 6y agoOne would argue that you should change your string fixtures to match and verify that the new API response doesn't break anything with your existing API client. Then you change the API client and verify that all the old tests still work as expected. Better yet is if you keep the old fixtures and the new fixtures and ensure that your API client doesn't suddenly throw errors if the API server downgrades to before the new field was added.