My project consists of several _spec files, and all the tests passed until I renamed one of the _spec files. The renamed file contains several tests, and the error occurs on the first one (and if I comment on this first test, the next one comes out in error, and so on). For all the tests, I check that the output (a multi-line character string) corresponds to what was expected. The error always occurs on the first line, as if the behavior of the source file algorithm (which generates the string in question) had been altered by the renaming!
I ran several renaming tests, and came to the conclusion that any filename would do, except precisely the one corresponding to the source file. However, this problem doesn’t occur for other specs files that have the same name as the source file.
I also cleared Crystal’s cache, but that didn’t change anything.
There is, I suppose, a rational explanation for this.
A clue?
The renamed file is spec/rowgroup_spec.cr in the development branch.
Running the specs should generate the error, rename spec/rowgroup_spec.cr to anything else, and no error !
[Edit] I omitted to say that running crystal spec -v spec/rowgroup_spec.cr alone does not generate any error !
… and also that moving spec/row_spec.cr from directory spec/ prevents the error from occurring.
Ah so it’s a spec failure, not an error. Also seems the error is coming from table_pack_spec.cr not rowgroup_spec.cr.
I looked thru the code a bit, and are you sure it’s not just due to your tests being “unsafe?” I.e. one spec could be mutating some global setting that causes another test case to fail since it’s in a diff state than if you just ran that one spec directly?
Running specs with --order=random seem to cause a random spec to fail, so it does seem like something is leaking state between each test case.
FWIW renaming that one file didn’t make a difference for me. But commenting out row_spec.cr did allow things to pass. Maybe that’s a clue…
I mean yea. When you run crystal spec, it’s just requiring all your test files and spec_helper, compiling a temp binary, and running it. Much like as if you do crystal run file.cr.
I’d guess $ crystal env CRYSTAL_CACHE_DIR, but looks like it mainly just has the .o files versus the actual temp binaries. But why? What are you wanting to do? Might be easier to just add some require to your spec_helper for each spec, then do a crystal build spec/spec_helper.cr and use that.
crystal spec is pretty much equivalent to crystal run spec/**/*_spec.cr. You can just turn that into crystal build spec/**/*_spec.cr -o spec_runner to get an executable program.