> I usually prefer test submodules because I like the proximity to the > code being tested. Plus in Emacs racket-mode I can fold/hide the test > submodules if they ever become distracting.
Nice feature. Btw thank you for making racket-mode :) > Exceptions to "usually": > > - Even with the ability to hide/fold tests, if the ratio of tests to > tested is really large, I may move tests to their own file. > > - If I'm implementing my own `#lang my-lang`, it's usually simpler to > have a separate test file with `#lang my-lang` at the top. That sounds very sensible. Test submodules as default and when tests get too large use separate test file. > Startup will be fastest if you `raco make` the foo.rkt file to a > compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or > via #!) it will load the compiled/foo.zo provided it's not older. > > (Otherwise the .rkt file must be parsed and expanded each/every time > you run. This includes test submodules, even though they won't be run. > In addition, expansion time can be significant with non-trivial > macros, including but not limited to Typed Racket.) Very interesting, this reduced the start up time significantly and my small script starts nearly instantly now. So for macro heavy code 'raco make' is the way to go. Can I use 'raco make' for everything or does it make debugging more difficult? Thank you very much for your help. Greg Hendershott <greghendersh...@gmail.com> writes: > I usually prefer test submodules because I like the proximity to the > code being tested. Plus in Emacs racket-mode I can fold/hide the test > submodules if they ever become distracting. > > Exceptions to "usually": > > - Even with the ability to hide/fold tests, if the ratio of tests to > tested is really large, I may move tests to their own file. > > - If I'm implementing my own `#lang my-lang`, it's usually simpler to > have a separate test file with `#lang my-lang` at the top. > > >> I observed that test submodules increase the start up time of racket scripts. > > Startup will be fastest if you `raco make` the foo.rkt file to a > compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or > via #!) it will load the compiled/foo.zo provided it's not older. > > (Otherwise the .rkt file must be parsed and expanded each/every time > you run. This includes test submodules, even though they won't be run. > In addition, expansion time can be significant with non-trivial > macros, including but not limited to Typed Racket.) > > > > On Thu, May 21, 2015 at 6:25 AM, Atticus <attic...@posteo.org> wrote: >> Hello, >> >> What is the recommended way to add tests in racket? I was looking >> through the racket documentation and there are two options for adding >> tests, using test submodules or using a separate file for tests >> (rackunit documentation). Some authors seem to prefer one over the other >> for example pollen >> (https://github.com/mbutterick/pollen/tree/master/tests) uses separate >> files and the author of racket-2048 >> (https://github.com/danprager/racket-2048/blob/master/2048.rkt) uses >> test submodules. >> >> Are there any advantages/disadvantages of using test submodules vs >> separate test files? Or is it just a matter of personal preference? >> >> It looks like that test submodules are more convenient and flexible but >> I observed that test submodules increase the start up time of racket >> scripts. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
