Closed kenloburn closed 6 years ago
@kenloburn great point!
@OGKevin @dnl-blkv Any idea if/when this will be looked into?
@kenloburn this is a major rework. So, not providing any dates yet.
@kenloburn Just a little update, we haven't forgot about this. It will be on the roadmap after callback models, decoder improvement for callback models and some minor patches 👍
After internal discussions, we concluded that ws will not move away from the static HTTP methods.
I would suggest you create a mock object and mock the static call via this mock object.
In the current implementation of the SDK static methods on classes are used to make requests.
For example:
This is not good for developer experience as it makes it non-trivial to implement the SDK in a project with high unit test coverage.
Imagine for example that in my project I have a
FinanceService
that has a method to accumulate total spend on saturday + sunday. If I expressed the service like this:Writing the unit test would not allow me to mock the API HTTP request very easily as there is no simple way to ensure that
Payment::listing
does not make an actual HTTP request, or to influence what the return value would be.There is a workaround I could do on my end, but it involves wrapping each individual resource that makes HTTP requests in a wrapper object like this:
To be able to mock (the result of) API HTTP requests in a unit test designed to test only the logic of the service method, and not invoke an actual API HTTP request (or even obtain/instantiate an ApiContext/session with the API):
This would mean that I would end up maintaining code that is domain specific to bunq but somehow physically located in the codebase of my own projects.
Ideally, the SDK is designed in a way that there is no need to invoke static methods to make API HTTP requests - this will make the DX much smoother in modern PHP projects.