Just to add more context: Bcrypt is slow by design. Password hashing needs to be slow to provide the security they give. Usually in tests one would dial down all the knobs, which allow it to be faster, or even replace hashing with a dummy.

One way would be to wrap it in a behaviour module

defmodule MyApp.Accounts.PasswordHash do
  @callback hash(String.t) :: String.t
  @callback verify(String.t, String.t) :: boolean

  impl_mod = Application.get_env(MyApp.Accounts.PasswordHash, :impl)
  
  defdelegate hash(value), to: impl_mod.hash(value)
  defdelegate verify(value, hash), do: impl_mod.verify(value, hash)
end

and have different implementations for test and dev/prod, where in the former one it would return a string

# this would probably be defined in test/support/
defmodule MyApp.Accounts.PasswordHashDummy do
  @behaviour MyApp.Accounts.PasswordHash
  def hash(value), do: "hashed_" <> value
  def verify(value, hash) do
    "hashed_" <> value == hash
  end
end

and in the latter – delegate to bcrypt

# defined in lib/
defmodule MyApp.Accounts.PasswordHashDefault do
  @behaviour MyApp.Accounts.PasswordHash
  defdelegate hash(value), do: Bcrypt.hash_pwd(value)
  defdelegate verify(value, hash), do: Bcrypt.verify_pass(value, hash)
end

and the appropriate implementation module would be set in env’s config

# config/config.exs
config MyApp.Accounts.PasswordHash, impl: MyApp.Accounts.PasswordHashDefault

# config/test.exs
config MyApp.Accounts.PasswordHash, impl: MyApp.Accounts.PasswordHashDummy

and the rest of the app would use MyApp.Accounts.PasswordHash.hash/1 and MyApp.Accounts.PasswordHash.verify/2.

Did you try reducing log_rounds in test env, as advised in step 3 of the installation guide? This is what I typically do in all of the projects, and tests are running smooth then. I never had to do this complex mocking of bcrypt.

You can use async exunit with tests against a database:
https://hexdocs.pm/ecto/testing-with-ecto.html#content

Basically the way to think about it is that you have your database sandbox itself so each test exists in its own parallel universe that gets generated when you perform a checkout operation. As long as your access queries run in the same BEAM process it should know which database sandbox instance belongs to its parallel universe. Also I think if you shoot of a Task it should also pass that information to the Task. If your database query goes through a GenServer, you might have a hard time (though i have done this and deeper parallel universes are doable, I would say it is not really for beginners).

You can also mock your database (or any module, really) module using Mox: https://hexdocs.pm/mox/Mox.html. There is a similar concept of tying the test’s process to the Mock system’s internal notion of parallel universes which track what test is doing what mock.

You can even do full on acceptance test (I currently run acceptance tests (total 10s) alongside my unit tests that check out a chromium headless and pass the parallel universe information using Hound and then using a plug associate the webserver’s BEAM process to exist in the same universe as the test that shoots off the query). I would say that this is kind of mid/advanced-level sophistication and not something I would necessarily pursue as a beginner, but I’m happy to answer questions for you if you are interested in doing this.

A few general points: 1) turn on async. Even if your tests are stateful, refactoring them to be able to exist in ‘parallel universes’ forces you to think about your architecture and really know what pieces of state bottleneck your system. In general you want to minimize these, and pushing on the async will expose the troublesome parts. Crazy sh*t will happen. You will HAVE to think about race conditions and you’ll step through things and red text will appear all over the place. You can tear your hair out or enjoy the ride, it’s a matter of perspective. 2) Keep in mind that tests within a module do not run asynchronously (although they are scrambled) so if you have a module with a ton of long-running tests you might be served by breaking them up. 3) keep in mind that a test is just a process! You can do things like send them messages and trap them with receive blocks if you are, say, spawning a sidecar process to do a quick thing.

I guess my unbiased opinion is that Testing in BEAM -especially with elixir- is like a whole new mind-blowingly awesome experience that you just won’t get anywhere else so take it in!

I have this experience before, and find out that the culprit is bcrypt. Bcrypt is slow. So maybe you want to check your test setup, especially user to see if you use Bcrypt to hashed your password everytime you create a user in test environment.