Make `ModelledResponse<T>` testable
Opened this issue · 2 comments
Feature request
Is your feature request related to a problem? Please describe.
Hi. I am trying to unit test the this library and I am coming across the issue of ModeledResponse<T> not being testable.
ModeledResponse<T> does not have a parameterless constructor, meaning that a framework like NSubstitute or Moq cannot create a proxy object easily.
ModeledResponse<T>.Trip/ModeledResponse<T>.Trips are both inaccessible properties making them unusable using a Mock wrapper like what Moq does (see below).
_myMock.Setup(obj => obj.Trip = fakeTripInstance)
Describe the solution you'd like
I would like for either ModeledResponse<T> to have a parameterless constructor and for the JSON deserialization process to happen outside the constructor, or for the behaviour to be contained within some kind of class outside of ModeledResponse<T>.
An alternative is to have ModeledResponse<T> inherit from a new abstraction IModeledResponse<T> where T : BaseModel.
This is probably preferred as it doesn't require a reconsideration of how conversions are handled. This would also mean that IPostgrestTable<T> and Table<T> would need their response types to be updated respectively.
Describe alternatives you've considered
I have tried numerous mocking frameworks with these classes and how their are configured means they are very sealed and unmockable.
Happy to make a PR if need be 😃
If the interface route is taken, then potentially there can be two response implementations: ModeledResponse<T> where is the BaseModel, and ModeledResponseCollection<T> where T is the BaseModel. The collection would have an immutable collection of T instances, and the single response would just have the single T instance.
The value add would be: mocking would be easier as you can mock a collection of T or a single T and assign to the mocked instance. Secondly, it means that response values just have the single object store (ICollection<T> or T) which would simplify things a bit. It also would make the interface clearer to the end user of the SDK as to what the endpoint returns.
The interface option seems to be the better of the two - Would love a PR if you’re interested in doing one!