Closed compdesigner-nz closed 1 month ago
I also posted on Discord:
https://discord.com/channels/839993398554656828/1006358244786196510/threads/1237331814360551466
Good call! Can you check #93 and see if that's what you're looking for?
Looks good to me
Available in v4.0.1
Thanks for sorting @acupofjose! Much appreciated. When will these changes bubble through to supabase-csharp
?
I’ll get to it probably this evening or tomorrow morning!
Awesome! Thanks for that. Getting this fix has been so much faster than other SDKs I've come across. I appreciate it 🙏🏼
Luckily an easy one to implement (and one that should've been implemented earlier!) - had a few minutes and went ahead and bumped the main repo. Should be seeing v1.0.1 hit nuget in a few minutes. Happy deving!
Wicked, this stuff now works with common testing frameworks like Moq and NSubstitute 😍 How good!
Feature request
I have recently started using this client library for doing some database operations across a series of services for a product I am making, and I would like to mock our the client and methods so that I can isolate the behaviour of my services.
I have opted to use Mock, NSubstitute, and Bogus as my mocking frameworks.
I would like to create mocks of
IPostgrestTable<TModel>
/Table<TModel>
so that I can override/implement the desired behaviour using the above frameworks.When reading through the codebase, I noticed that
IPostgrestTable<TModel>
's methods (where applicable) return the concrete typeTable<TModel>
instead ofIPostgrestTable<T>
.Table<TModel>
's methods are not virtual, and as a result, I can't mock out my client, as the interface has concrete return types, and the concrete type does not have methods that can be overridden.Describe the solution you'd like
I would like for
IPostgrestTable<TModel>
's methods to have their return type changed fromTable<TModel>
toIPostgrestTable<TModel>
. This means that the interface can be implemented usingNSubstitute
and mocked out, successfully enabling future unit testing.Describe alternatives you've considered
I noticed that unit testing for this package is done using a docker container. I could do this, however, I would like to separate out my integration and E2E testing from my unit testing. I would also prefer to not have to mock out quite a complex database within the container, as well as populate test data.