Atbash Cipher should have tests for decoding.

[borderite]

The current tests of "Atbash Cipher" in Common Lisp has no tests for the decode function. As the canonical test data has a few of them, I think that they should be implemented.

[github-actions]

Hello. Thanks for opening an issue on Exercism 🙂

At Exercism we use our Community Forum, not GitHub issues, as the primary place for discussion. That allows maintainers and contributors from across Exercism's ecosystem to discuss your problems/ideas/suggestions without them having to subscribe to hundreds of repositories.

This issue will be automatically closed. Please use this link to copy your GitHub Issue into a new topic on the forum, where we look forward to chatting with you!

If you're interested in learning more about this auto-responder, please read this blog post.

[BNAndras]

The exercise was added ten years ago so it predates the canonical test data. Syncing the test suite would break 130 completions but that’s not too alarming to me.

Given the instructions explicitly reference decoding, an argument can be made that they contradict the provided test suite which only tests encoding. In that case, an instructions append would be helpful if the maintainer doesn’t want to implement the extra tests. The tests.toml file probably should be updated then to record that those decoding tests weren’t added.

[verdammelt]

I'm going to re-open this issue. Didn't know that atbash has a bunch of tests this track does not implement. I wonder why the configlet sync checking is not highlighting them?

[borderite]

@BNAndras, @verdammelt It seems that tests.toml contains all tests from the canonical test data. When I ran

bin/configlet sync --tests --update --exercise atbash-cipher

the result was "The atbash-cipher exercise has up-to-date tests!" Anyway, I am working to add the missing decode tests to the atbash-cipher exercise.

[BNAndras]

Configlet compares the local tests.toml to the upstream problem-specifications one. This system has been in place for a few years, but the local tests.toml reflect the upstream tests that were available at the time plus any additional changes since then. Configlet thinks we’re up to date on the tests here because there haven’t been changes upstream since the tests.toml file was created.

So someone should compare implemented tests vs what’s in each tests.toml to make sure unimplemented tests aren’t falsely included in the toml. I just did that a few months ago for the Emacs Lisp track actually.

[borderite]

@BNAndras Let me verify if I understood you correctly. Configlet initially creates tests.toml based on the canonical test data available at the time. If some of the tests in the tests.toml file are not implemented, configlet will not know that. Is this correct?

[verdammelt]

@borderite oh I didn't realize you were implementing the missing tests and I went and did it. Please submit your PR; we can merge yours rather than mine.

[borderite]

@verdammelt If you have done it, please merge yours. It is not a big deal, because my job was almost nothing. The script bin/lisp_exercise_generator.py was amazing. It automatically created new tests with no errors. The only thing I did was to write an example solution, which I would do anyway as a student.

[verdammelt]

@verdammelt If you have done it, please merge yours. It is not a big deal, because my job was almost nothing. The script bin/lisp_exercise_generator.py was amazing. It automatically created new tests with no errors. The only thing I did was to write an example solution, which I would do anyway as a student.

OK, just allowing you to get the exercise reputation points if you wanted them.

I should try that test generator out sometime... I did the "hard way" (which wasn't very hard at all).

[borderite]

@verdammelt I am not very interested in the reputation points very much, as I probably don't understand what they matter for? I used the generator but manually inspected the output, of course. I was very impressed, becuase it worked perfectly (but in this particular case).

[BNAndras]

Qualifying for monthly or even lifetime insiders at https://exercism.org/insiders is the main benefit I think since you need X amount of rep in a certain time frame. Otherwise, building rep is used to identify potential maintainer candidates semi-regularly. I don’t think building / authoring category rep can’t be used for much else to be honest.

Mentoring category rep on the other hand is used to unlock supermentor status on a given track which gives you a special Discord channel and then access to the track’s representer. That’s used for automated feedback but only if the track has a custom one implemented.

Otherwise, rep is mainly used for the contributing leaderboards (weekly, last 30 days, last year, and all-time). The all-time board is dominated by folks who have been around since the v3 launch though.