Using `racket-test` without a test submodule

[elibarzilay]

This is re a post made on the mailing list recently (cc @nineluj) by a student in my class who is trying to use racket-mode with Emacs.

The problem is that the modules that are generated by the class language(s) don't have a test submodule, and instead tests are just toplevel expressions. (The reason for that is that it predates submodules, and I don't have enough time to allocate to reorganizing the languages and the surrounding machinery to all switch to submodules.) However, it looks like it should be relatively easy to make such a situation work: IIUC, racket-run (after the recent 5226366) will run a main submodule, and if that's not present, it will run the module itself --- but it does not include coverage information. OTOH, racket-test can do that, but it is hard-wired to running the test submodule.

Would it be possible to make racket-test run the module itself when there is no test submodule in an analogous way to racket-run & main? That would make it be useful in cases where there is no test module. If not, then maybe a custom option that can make it try the module itself rather than the submodules? And another option would be to add the option of coverage information for racket-run too? (I'd try patching it myself, but I couldn't figure out the details.)

FWIW, I managed to make the languages add a (module+ test) at the end, which made it possible to use racket-test and see the coverage results, but the REPL that you get after that is in the context of the test submodule, and probably due to low-level games with typed-racket, the resulting repl is useless (has no type information).

(BTW, the package that is used is in the old archive format, it can be installed with raco -DA.)

[greghendershott]

I searched and I think you mean this post: https://groups.google.com/g/racket-users/c/_264OkcugwM/m/trrMVmQJAQAJ?

Would it be possible to make racket-test run the module itself when there is no test submodule <--snip-->? That would make it be useful in cases where there is no test module.

I think that should be possible and is probably the best way to handle this.

---

p.s. Maybe nit-picky but maybe useful to know:

The thing I snipped from the middle of your sentence was

in an analogous way to racket-run & main

• Currently racket-run is bound by default to F5, and works most similarly to DrRacket in various ways.

• racket-run-module-at-point is bound by default to C-c C-c and runs/enters the specific module innermost around point. This is what I actually use day to day. The innermost module could be simply the file's module.

• racket-test C-c C-t is really a flavor of racket-run-module-at-point, hardwired as if point were within a test submodule. And, if you use a prefix with it, C-u C-c C-t, it will instrument for coverage and highlight uncovered spans. (Which is C-u and optional because doing so is "heavier".)

So TL;DR I like your suggestion, to have racket-test run the file module if no test submodule exists. I just wanted to point out it wouldn't work exactly like how racket-run and how it handles main and test. Whether or not that will turn out to matter, for you or your student's exact use case, I don't know. Anyway I'm happy to make the change and find out.

[greghendershott]

More details as they bubble up from my memory:

The other cool (IMO) thing about racket-test is that it gives you a REPL in the test submodule -- you can explore things there. I find that really handy, when wanting to exercise individual tests in the REPL that may use helper functions defined only in the test submodule, etc.

The way racket-run works, like Dr Racket, is that it may automatically evaluate certain other submodules like main or test, but you always end up with a REPL in the outermost, file module. IMO, sadface.

So I don't want to change racket-test to work like racket-run, exactly. I want it to still work like racket-run-module-at-point. Instead it would be literally what you said: IFF a test submodule does not exist, then run the outermost, file module (with coverage instrumentation and highlighting) and with the REPL ending up there.

[elibarzilay]

The reason I mentioned racket-run is that it sounded like it's doing the main-or-toplevel search already, and in addition, if you're thinking about it as a DrR equivalent, then it could gain a customization option to show coverage. But I agree that it makes more sense to make racket-test do a similar test for test-or-toplevel --- and if that also leaves the resulting REPL at whatever was used, then everything should work perfectly. Thanks!

(Sidenote: a very nice feature of DrR is that the coverage information gets updated live, as you enter additional REPL expressions... This turns out to be really useful for demonstrating execution in a lazy language since it visualizes the non-execution and later the by-demand execution of various bits.)