3 ms·
Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step. Also, perhaps some non determinism is allowe
by Peaker 11y ago
Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step.
Also, perhaps some non determinism is allowed for the tests. Then runtime safety isn't equivalent to compile time safety.
- pron 11y ago> Also, if tests take a while to run, it's nice to get the feedback from the compile step, rather than the run step. True. We do that in Java, too. The idea is that you don't want to let methods use any "global" IO access (like System.out or new FileOutputStream) -- only IO streams that are passed in as arguments (which can then be mocked) -- so you use an annotation processor[1] to prohibit any such use; it's automatically picked up, loaded and used by all IDEs to mark any use of "prohibited operations" as errors while you type. Square/Google's Dagger DI library uses the same approach to make sure -- at compile time, with IDE support -- that all dependencies are satisfied. Again, this works without requiring any use of new/non-standard APIs. [1]: It's a class that gets run during one of the compilation phases, like a poor-man's pattern macros.