Supabase instance for testing?

[ar1a]

I'm currently working on a supabase react hooks library but I'm wondering how to test my hooks. I'm finding it difficult to mock the supabase api, is there a permanent instance with a read-only database that also accepts mutations? For example, an upsert that will return the right response, pretend it worked, but doesn't change the database (to avoid abuse).

[egor-romanov]

Hi @ar1a, I don't think we have such thing currently, but you can use one of your free projects to do such thing or a local setup, that you can now run using one CLI command.

[cayblood]

@egor-romanov I'm trying to set up a test instance as you suggest. One thing I've struggled with is how to properly reset a remote instance so that I can test migrations from scratch. The cli doesn't seem to support it, and dropping the public schema seems to cause some important supabase proprietary roles to be removed. Any suggestions?

[egor-romanov]

Hey @cayblood, thanks for waiting for the response :) I would use pg_dump to save the state to which you want to rollback after.

[cayblood]

Thanks @egor-romanov. Forgive my ignorance, but can the result of pg_dump always be applied to any database, or do I need to somehow wipe my database clean before applying it?

[egor-romanov]

Yep, you're right, you should drop the public schema before restoring. I would limit dump-restore to public schema only btw

[ghost]

I was going to use a local supabase for development and testing until I found this issue supabase/cli#825
and then I decided to try and use a cloud db for development, but that is now being stymied by the lack of ability to reset the remote db to a clean instance.

[angus-clark]

My solution around this was to write my own test manager which kept track of tables and users created. It would then delete all entries from the tables before the next test is run using the setup/teardown methods. Probably not the most efficient solution and requires adding a bit more code to your tests but works for me.

[egor-romanov]

If you need the same initial state all the time, you could just run a set of migrations to reset the public schema to the initial state before/after tests. And use supabase-js methods to delete all users and clean up storage.

[ghost]

Thanks! Automating data cleanup to reset things for tests will certainly work well enough for me.

I actually don't need initial state all the time, but while I am developing the initial migration for any project - I will need it during all of that time to ensure that things work from a clean instance.

So, I decided I will just use local development to create the initial migration. Then every developer after that should just be able to use our normal up/down migration system with any local or cloud instance without much trouble.

As for the mismatched locale being used by local and cloud Postgres, I made a pull to rectify that and it was just merged now so I'm thankful for the responsiveness here and I'm looking forward to working with Supabase some more!