This looks great! Thanks for the library.

The GitHub link doesn’t seem to work though?

Fixed!

@zachallaun this looks great! I’ve tried it and so far this looks promising. I have one question though:
the interactive dots during the test suite run only appear at once after everything is finished. On bigger codebases this would be a no-go, since the immediate test feedback is really important here.
Is there a way to bring this “progress-bar” feeling back?

Also nice that you link to https://insta.rs/ and GitHub - janestreet/ppx_expect: Cram like framework for OCaml · GitHub , the ideas behind those libraries are quite cool!

More links, if anyone is interested:

• Jane Street Blog - Testing with expectations
• Jane Street Blog - What if writing tests was a joyful experience?
• Testing - Real World OCaml
• “Expect tests” make test-writing feel like a REPL session | Hacker News (discussion on HN)

Thank you so much for trying it out and for the question!

To make sure I better understand, are the dots appearing all at the end even when there are no prompts from Mneme? If so, that’s a bug and can/should be fixed. It’s currently expected that nothing will appear during prompting, however, even though async tests are continuing to run in the background — I’m currently suppressing output to prevent garbled terminals during prompting.

One possible solution I explored was a “raw mode” TTY, so that Mneme would have full control over the terminal and get keys on press instead of on-enter. This turns out to be a really tricky problem in Elixir/Erlang, however, though some changes coming with OTP 26 might make it easier in the future.

This article and discussion is what got me working on this. I’ll add an “additional reading” section to the docs with some of this. Thanks for sharing here!

I mean the test run without any prompts, it looks like the process is hanging and then all the dots appear at once.

Raw TTY sounds indeed like a challenging problem, especially with async tests running. I currently do not a good idea how to approach it. Should I open an issue on the repo with a reproducible example?

If you have one, that would be great! Thank you!

Hey @zachallaun , here is a small demo:

• https://github.com/mindreframer/mneme_sample

I run tests in IEx, so I’ve adjusted mneme to restart on Mneme.start() fn call.

Thanks so much for the demo! I’ll see what can be done.

@mindreframer I’ve just published 0.1.1, which pretty dramatically reduces the performance gap between auto_assert and assert. If you are able to give it a try and let me know what issues persist, I’d greatly appreciate it.

This was most definitely worth pursuing! Your demo made is super clear just how slow auto_assert was compared to normal asserts.

My intuition about compile-time vs. runtime costs was wrong in the context of .exs, since all compile-time costs are incurred every time you run the test. By dramatically simplifying the code that the auto_assert macro produces, an unscientific benchmark of running a test with 100 generated auto-asserts goes from taking ~3 seconds to taking 0.2s (compared to 0.05s for normal asserts).