exercism/ruby: the Ruby track, its test generators, and the rake tasks that run them

An exercise is a test file, a solution, and often a generator

The exercism/ruby repository is the Ruby track for Exercism, and the README is written for contributors rather than learners. The files for an exercise live in `exercises/<slug>`, where the slug is a unique nickname composed of lowercase letters and hyphens, for example `clock` or `atbash-cipher`. Inside that directory there are two files you always get, a test suite named `<exercise_name>_test.rb`, and an example solution at `.meta/solutions/<exercise_name>.rb`, where the exercise name is the slug with hyphens replaced by underscore characters, so `atbash_cipher`. If the exercise has a test generator, the directory also contains `.meta/generator/<exercise_name>_case.rb`, and a few exercises use a custom test template at `.meta/generator/test_template.erb`. That layout is the whole contract for adding an exercise, and it is why the track can be regenerated mechanically rather than maintained by hand exercise by exercise.

Canonical data is the shared source of truth for most tests

Most exercises can be generated from shared inputs and outputs called canonical data, and the README points to the problem-specifications repository to find out whether a given test has canonical data. This is the mechanism that keeps language tracks consistent with each other. A problem is defined once, as a JSON document of input and expected output pairs, and each track writes a generator that turns that document into idiomatic test code for its own language. The README also names the awkward part of the job: while `lib/generator/exercise_case.rb` provides helper functions, it remains the responsibility of each exercise's generator to interpret its canonical-data.json in a stylistically correct manner, for example converting string indices to integer indices. Generators are therefore not purely mechanical, and a track maintainer is expected to know what a good test file looks like in that language.

rake is the entry point, and it knows about the example solution

Running the tests is where the tooling earns its keep. The README says to run the tests using `rake` rather than `ruby path/to/the_test.rb`, because `rake` knows to look for the example solution and to disable skips. You name the problem and you are set:

rake test:clock

Arguments pass through to the test command, so a name pattern filter works the way minitest expects:

rake test:clock -- -p

and a regular expression narrows the run to a subset of tests:

rake test:hamming -- -p -n="/identical/"

The README is precise about the syntax here, noting that flags with an attached value must take the form `-flag=value`, and that a value with spaces needs quoting. The reason to prefer `rake` over invoking the test file directly is the important part. Because the tests live alongside a reference solution, a raw `ruby` invocation can pass against a stub or skip cases, and the rake task is what makes the suite behave like a self-check. Ruby 3.4 or newer is the supported version, Minitest ships with the language, and older versions may work but are not officially supported.

Pull requests carry the project's own rules about scope and style

The contribution rules are stated plainly, and they say as much about how the track is maintained as about the code. Fixes to existing test suites are welcome, including missing tests, interesting edge cases, and improved APIs, as are new problems. If you are unsure, open a GitHub issue first and discuss the change. Changes should be submitted to a single problem per pull request unless the change is general across many problems, with formatting given as the example. The repository ships a local checker you can run:

    bin/local-status-check

and a script to install the same checks as a git hook:

    bin/setup-git-hoooks

For the test files specifically there is a minimal style guide backed by the `rubocop` gem, using the `.rubocop.yml` in the repository root. You run it with `rubocop -D`, which ignores the example solution and gently suggests style for the test code. The `-D` flag exists so that individual cops can be switched off for a line with a `# rubocop:disable CopName` comment, which is how a generated or intentionally unusual test file stays readable without failing the whole check.

READMEs are generated by configlet, not written by hand

Every exercise must have a README.md file, and the README is explicit that these should not be created manually. They are constructed from shared metadata that lives in the problem-specifications repository, and the `configlet` tool does the work. The process it documents has three steps: clone the problem-specifications repository into an adjacent directory, fetch the configlet binary for your system with `bin/fetch-configlet`, and then generate the readme for a particular exercise with `bin/configlet generate . --only rotational-cipher`. The rotation of tools here is worth noticing. The `rake` tasks run the tests, `rubocop` checks the style of the test code, `configlet` produces the student-facing README from upstream metadata, and `bin/local-status-check` and `bin/setup-git-hoooks` wire the CI checks into a local loop. A contributor touches all of these, and a partial contribution that adds a test file without regenerating the README will look different from a complete one.

The repository is a track, not a library, and it says so in its topics

The layout of the repository makes the scope obvious. There is an `exercises/` directory with the problems, a `lib/` directory holding the generator helpers, a `generatorv2/` directory, `concepts/` and `reference/` directories, a `docs/` directory, `test/`, `bin/` with the scripts, a `Rakefile`, a `Gemfile`, a `config.json` describing the track, and an `exercise-concepts.todo.json` that records which concept exercises still need to be written. The `package.json` is minimal and exists for tooling rather than runtime, with `husky` and `pretty-quick` for pre-commit formatting and `prettier` for the non-Ruby files. The licence is MIT, and the project was pushed to on 2026-10-21, which is recent work on an active repository even though there are no GitHub releases to point at. One detail in the repository topics deserves a mention rather than glossing over: the topic list includes `community-contributions-paused` alongside `maintained` and `exercism-track`, which tells you that the code is being worked on while outside contribution is on hold. That changes what to expect from opening an issue.

Editorial conclusion

exercism/ruby is worth reading if you maintain the Ruby track, port an exercise from another language, or want a worked example of how a shared problem specification turns into generated tests in a given language. It is not a library and not a teaching resource you install, so it does not fit a team looking for Ruby components to use in production. Before you open a pull request against it, read the contributing rules in the repository, run `bin/local-status-check` locally, and note that the repository's own topic list marks community contributions as paused, which changes what a response to a new issue is likely to look like.

Frequently asked questions

Official sources

1. exercism/ruby on GitHub
2. Issues
3. License: MIT
4. Project website
5. README