-
Notifications
You must be signed in to change notification settings - Fork 521
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
Add test generator #1722
Add test generator #1722
Conversation
The use case for this is extremely rare, to the point where I think it's more benefitial to keep the repository simple by deleting it.
This is super complicated and unmaintainable.
All of these tests are there to prevent people from making mistakes, when the better approach is to automate that work.
Should come in handy as reference, for tests and generation. Also fix a couple inconsistencies in the config.
This is completely undocumented. I guess it's sorting some stuff in the config. Why? I don't know.
This is not the place to teach Windows users how to run Bash scripts.
makes the repo structure less confusing
The scope of these scripts is too big for Bash. They will be rewritten in Rust, with functionality to synchronize with problem-specs.
Both rustfmt and clippy are installed by default these days. I definitely think these tools should be recommended to students, but the installation page is not the best place for that.
```sh git rev-parse --show-toplevel ``` will always work, whereas relative paths may break when a script is moved to a different location in the repository.
One could simply run `configlet sync` anc read from `~/.cache/exercism/configlet/problem-specifications` instead.
In terms of code style, we should just go with the default for any specific language. Rust has rustfmt. Shell scripts should be kept to a minimum such that it doesn't matter.
Some become unimportant when Rust is recommended for non-trivial stuff. Some are now tested, so they don't need to be mentioned explicitly.
I'm not sure why this is the current convention in this repo. Rust files are always snake_case. I'll leave it for now, but might refactor at some point if I can't find the reason.
Some test descriptions have commas and other shenanigans in them. `slugify` solves all those problems with one filter.
}, | ||
{ | ||
"slug": "kindergarten-garden", | ||
"name": "Kindergarten Garden", | ||
"uuid": "c27e4878-28a4-4637-bde2-2af681a7ff0d", | ||
"practices": [], | ||
"prerequisites": [], | ||
"difficulty": 1 | ||
"difficulty": 1, | ||
"topics": [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the topics
key added? It is only really there for inspiration for the practices
/prerequisites
fields, but it serves no purpose from Exercism's viewpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened a separate issue for me to consider what to do with this field / how to document it properly. In this PR, they are only added for simple and consistent de-/serialization.
I may or may not clean up empty topic fields when I decide what to do on the separate issue.
This adds a test generator written in Rust. The main goal is to be able to quickly synchronize with problem-specifications. In the process, I rewrote a bunch of Bash scripts in Rust to clean up the tooling.
I changed a couple of things in the track config.json, including on deprecated exercises. Mostly for more consistent de-/serialization. Maybe that's a big no-no?
This is the first step - to have a generator in the repo. The next steps will be to apply it one-by-one to all exercises present in the problem-specifications repository. That will probably lead to iterative changes to the generator as well. Once that's done, I will add CI tests to make sure all exercises are in sync with the version of problem-specifications pinned here as a submodule. Updating will then be a matter of pulling the submodule and pleasing CI tests.
The following is intended as guidance for reviews as well as the commit message of the squash commit if this gets merged.
Add test generator
cleanup dev tooling
bin/
check_exercises_for_authors.sh
count_ignores.sh
verify_exercise_difficulty.sh
lint_tool_file_names.sh
lint_trailing_spaces.sh
check_uuids.sh
:configlet lint
covers that alreadyensure_lib_src_rs_exists.sh
:this is not an issue if exercise stubs are generated
clean_topics_vs_practices.py
:applies undocumented standards (max 10 practice exercises per topic)
fetch_canonical_data
:we now have the submodule for this
cleanup documentation
CONTRIBUTING.md
andmaintaining.md
README.md
toCONTRIBUTING.md
REAMDE.md
from Python trackapply conventions and guidelines in a couple places
where the new Rust tests found deficiencies
replace Bash-based exercise generation with Rust-based one
(deleting the related
util/
Rust crates)inspired by the python track using Jinja for this purpose
apply test generation to acronym exercise to validate MVP