Phoenix how to disabled Ecto sanbox in test- Test without sandbox

Just out of curiosity, have you simply tried searching all the text files that make up your Elixir codebase for SQL.Sandbox or even just Sandbox?

In my current application I don’t use the Ecto Sandbox either and everything in regards to testing and the database works the way I suspect you desire. However, if I or someone else had added code making use of the Ecto Sandbox to the project (a necessary step for it to be used: it’s fully opt in) and I wanted to get rid of it, but couldn’t: I’d do that simple brute force search to see what remnants might have been missed.

Hi, can you share your:
mix.exs
config/test,exs
test/support/data_case.ex
and a simple test

Greetings

I strongly suggest you try my original suggestion of doing search for other sandbox references before diving into my code. Also, others here may have something closer to what you’re looking for in terms of standard Elixir development practice. But, if to do nothing more than to prove the old adage “be careful what you ask for”, please find the best I can do with your requests.

My code is source available (though not open source) and I will provide links to the closest analogues to a simple Phoenix project from my code, but know that my code is not going to help you, especially if you’re trying to come to terms with standard Elixir development practices.

My project has a fair number of non-standard/unconventional practices for Elixir development (reasons™, some good, some bad). A few of these to be aware of which pertain to you:

• For Phoenix:

  • It’s an umbrella project (due to the possibility of different release profiles; this is not an umbrella for logical code organization).

  • The Phoenix part of my application pretty strictly only provides Web and external API interfaces. There is no business logic or “contexts” beyond the minimum to make the external interfaces work nor is there direct database access from the Phoenix related code. Business logic, and data access, comes through dependencies.

  • The only Phoenix provided templates I use are those generated when calling mix phx.new --umbrella --no-ecto. I don’t use the generators and there is no Ecto at all configured in Phoenix.

  • The Phoenix parts of my application are the least developed at this stage.

• For database related code and testing:

  • All business logic, including logic requiring the database, are kept in standard (not Phoenix) Elixir projects which act in a library-like way and are very narrowly scoped to specific features. There are Elixir projects where these lower level libraries are orchestrated into full fledged applications, but again, these are not Phoenix projects, just normal old Elixir projects.

  • I use a custom database library which wraps Ecto to better meet my requirements. This library includes a bespoke database migrator and Repo connection management system using Ecto Dynamic Repositories.

  • Because of the custom connection management stuff, I don’t use any of the config/*.exs configuration files for Ecto configuration.

  • All testing of the database is done in these library-like Elixir projects and uses the custom database stuff just mentioned. The test themselves look like typical Ecto code because I don’t futz with the Ecto Query DSL.

So, again, if you are still fairly new to Elixir, Ecto, and/or Phoenix Framework my code will not help you and may well confuse you and lead you astray. But if you really want to continue on that path… your requests as best as I can fill them:

• mix.exs

  Main Phoenix mix.exs: https://github.com/MuseSystems/musebms/blob/next_version/app_server/platform/msplatform/mix.exs

  “my_app” mix.exs: https://github.com/MuseSystems/musebms/blob/next_version/app_server/platform/msplatform/apps/msapp_mcp/mix.exs

  “my_app_web” mix.exs: https://github.com/MuseSystems/musebms/blob/next_version/app_server/platform/msplatform/apps/msapp_mcp_web/mix.exs

• config/test,exs

  Phoenix test.exs: https://github.com/MuseSystems/musebms/blob/next_version/app_server/platform/msplatform/config/test.exs

• test/support/data_case.ex: I have no data_case.ex file anywhere in the application as I don’t use the generators.

• and a simple test:

  A data related test from one of the library components, though it is not enough to look at this test file to understand what is really happening behind the scenes with repos and database connections, you’ll need to look in the test/support directory and even then it won’t be standard Ecto repo management: musebms/app_server/components/system/mscmp_syst_perms/test/perm_test.exs at next_version · MuseSystems/musebms · GitHub

To really understand what’s going in this application and to navigate the application code any better you’ll need to read the docs at: Technical Documentation | Muse Systems Business Management System (what of them actually exists).

Cheers!

I am probably not understanding you well here but what exactly is stopping you from having several DB dumps that you can restore on top of each other? And then when you want to test a certain scenario that needs database dump 1, 4 and 6, you just make a mix task alias to clear up the test DB and then load those dumps in order?

I’ve done that too, several times in my career. There’s really no point in running expensive seeding scripts if the required test data barely changes; so just make one functional and good copy of the DB and pg_dump it and then pg_restore it before tests.

Thanks Dimitarvp, I made a mix between seed and test with sandbox and every thing work flawlesslly.

When in Rome, do as the Romans do

But it would be so convenient to be able to disable the sandbox temporarily at the end of a test in order to produce a database dump and maintain consistency across tests (because seeds can quickly become inconsistent when testing while developing — whereas the test is always right).

For example:

– A test creates 1000 users, including 20 administrators
– At the end of the test, by temporarily disabling the sandbox, I pg_dump the database (into “some-users.dump”)

– Another test starts from that dump by loading “some-users.dump”
– This test does many other things
– I dump the final result, again by temporarily disabling the sandbox, into “a-lot-of-work.dump”

– My third test starts from there by loading “a-lot-of-work.dump”

If I ever need to make further changes in the second test, I just run its test again and dump the updated database ( again by temporarily disabling the sandbox).

My third test then starts consistently from the updated “a-lot-of-work.dump”.

The way the sandbox works is:

1. start a database transaction at the start of the test
2. data gets inserted and updated in the database and read from the database within that transaction during the test
3. at the end of the test, roll back the transaction instead of committing it

Since transaction COMMIT never happens, the data is never really persisted in the database. So I don’t think pg_dump would have any access to it.

Thanks @nathanl, you’re right.

I don’t use sandbox anymore. Hence I can pg_dump my bdd.

Late to the party, but you can do Ecto.Adapters.SQL.Sandbox.start_owner!(Repo, sandbox: false) in your DataCase setup. This prevents wrapping each test in a transaction that is rolled back at the end of the test.

Some options like sandbox are passed to Ecto.Adapters.SQL.Sandbox.checkout/2. The behaviour is documented there.

At the risk of necromancing this thread once more:

you can do Ecto.Adapters.SQL.Sandbox.start_owner!(Repo, sandbox: false) in your DataCase setup

I sometimes use this to peek into the database state when working on a specific test case.

This is especially helpful when testing insert logic, e.g. for bulk upserts. Obviously, you will need to reset the tables manually when you are done to not interfere with other tests.