Thank you for the library, it looks quite interesting. I like how it’s functionality builds upon other Elixir mocking libraries. Can you talk a bit about how it’s implemented? I’m really curious how it’s able to safely override any call to external modules.

Sure, here it is: How it works — Repatch v1.6.1
Codebase is really small, around 1.5k lines, so you can read it in half an hour

Repatch 1.5.0

This is a big update which adds helpers on top of existing patch logic to support

1. Mox-style define/expect explicit DI mocking for behaviors.
2. ProtoMock-style define/expect explicit DI mocking for protocols.

That means that you no longer need to install a bunch of separate libraries, some of which require explicit dependency injection boilerplate, others don’t work with async tests, and so on. You no longer need to keep in mind the different limitations of these libraries with Repatch.

I’ve tried this update on the project of mine, I replaced all TestServer/Bypass, Mox, Patch and ProtoMock code with Repatch, made all of the tests async: true and tests now run 2 times faster, while testing code looks much more cleaner as a bonus.

Oh, I would love examples! Any links to PRs / commits to demonstrate a before/after?

The library looks great. For those who are more of self-controlled code, there is also Bex library to generate behaviours for whatever to be mox’ed.

Unfortunately, I can’t show the project, but I can give the numbers. It used to be 3 minutes sync tests + 1 minute async tests and now it is just 2 minutes async tests + a couple of seconds of sync tests. My goal is to make it possible to rewrite all tests with async: true.

The only tests I can’t make async are those which perform series of DDL transactions in postgres. Well, I mean, I can make them async by using unique database in each test, but it would consume more time to setup then time saved by async

Thanks for creating Repatch!
I think this is the best of all the mocking libraries with the least restrictions, and it should deserve a lot more recognition from the community.

Patching DateTime module for time travelling in timestamps

Do you have a helper module / small library that you use for this which you can share?
I needed time travel testing in literally every project at some point and I hate to reinvent it every time.

With Repatch I’m currently just doing this, but it’s probably too simple for most situations:

    {:ok, time} = Agent.start_link(fn -> ~N[1990-01-01 00:00:00] end)
    Repatch.patch(NaiveDateTime, :utc_now, fn ->
      Agent.get(time, fn t -> t end)
    end)
    # ...
    Agent.update(time, fn _ -> ~N[2010-01-01 00:00:00] end)

Hi, uhh, I mentioned it in “New horizons” because it was worth exploring. And I did some exploration and found out that

1. DateTime.utc_now uses System.os_time which uses :os.system_time. And :os.system_time can’t be patched
2. We can patch DateTime.utc_now but it will only replace this call, since, for example, erlang dependencies will use :os.system_time which will always return unpatched, real values
3. And there are also other functions like :erlang.monotonic_time which return different kinds of time

So my conclusion is that it’s not possible to use Repatch for 100% compatible time traveling. And it is not possible to use anything else, since erts implementation calls posix gettime directly, without any way to change it on erlang side only for some specific process.

My suggestion for you is to try to approach the problem another way: instead of travelling in time in order to make sure that some timers are triggered, you should try to make timeouts for these timers configurable and then set them up in tests accordingly.

Hmm, ok, thanks for digging.

However, so far, all my use cases of time traveling were possible by patching just NaiveDateTime and similar.
In my projects it mostly comes up with logic that involves ecto timestamps, and for those it is enough.
So I’d be happy with a good enough solution that only patches what’s possible.

But yeah, ideally we’d have travel_to like in rails that just works across the whole ecosystem..

Well, only thing that I can suggest to improve then is to use Repatch.patch(NaiveDateTime, :utc_now, fn -> ~N[1990-01-01 00:00:00] end) without an agent. You can then overwrite this patch with [force: true] option in the third argument.

But to be honest, I’d have a O_O look on my face if saw a test code like this.