Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow the Crystal convention of placing tests in a spec/ directory #47

Closed
daveyarwood opened this issue Nov 5, 2016 · 3 comments
Closed

Comments

@daveyarwood
Copy link

daveyarwood commented Nov 5, 2016

According to the Crystal Spec module documentation:

By convention, specs live in the spec directory of a project. You can compile and run the specs of a project by running:

crystal spec

Also, you can compile and run individual spec files by providing their path:

crystal spec spec/my/test/file_spec.cr

In addition, you can also run individual specs by optionally providing a line number:

crystal spec spec/my/test/file_spec.cr:14

Are we interested in following this convention? One reason I'm interested in this is that the excellent vim-crystal plugin has keybindings to run specs, but it only works if your project follows the convention of having your spec files in a spec/ directory.

If we're agreed, I'd be happy to contribute a PR updating the existing exercises.

@mhelmetag
Copy link
Contributor

Hey there!

Yeah... so we're following the second method (compile and run individual spec files) so that this track can follow the structure of the other track repos (so that the cli and other services can have a standardized way to find all the files).

I'm all for conforming with spec but... I'm not sure if there's a way to change the spec target directory (similar to how xelixir does it here). Unfortunately, I don't think we can configure that in a shard.yml (but if there is, by all means do it).

If you can figure out a way to keep the existing repo structure but also use crystal spec that would be awesome (keep in mind that currently we also have most of the tests set to pending so to actually run them during CI we do some sed magic as well).

@daveyarwood
Copy link
Author

Hi, thanks for taking the time to explain! I'm not sure I fully understand the problem, yet.

It looks like the Clojure track is somehow able to have exercises that each have src and test directories (following Clojure project convention)... this made me curious, so I dug into the exercism cli, api and trackler repos a little bit. Unless I'm missing something, I'm not sure that there is any requirement for the contents of an exercise folder in a track to follow any particular convention.

I see that we have a Makefile in this repo that manages running the spec files for each exercise. That could certainly be adjusted to cd into each directory and run crystal spec.

Am I missing something?

@mhelmetag
Copy link
Contributor

mhelmetag commented Nov 5, 2016

Ah I didn't know that xclojure had such a different exercise structure. Interesting! I think that it could work then. I'm still just a bit concerned about changing the whole structure of exercises after launching but... if it works, it works.

I say go for it.

I think the steps are to:

  • restructure the individual exercise dirs to have src and spec folders (or similar so that crystal spec works)
  • update makefile to edit test files (change pending to it) with new dir structure while running CI and also run crystal spec while running tests
  • update the docs for people on exercism so that they know which files to check-in and how to test (I think the one downside of this new configuration is that it makes it a bit more complicated to know which files to check in)
  • as well as update docs for other contributors to this repo so that everyone is on the same page about the new exercise structure

Since this is a pretty big change. I'm going to start a spec branch. It would be great if you could base your PR's off of that branch.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants