atbash-cipher: Use Tera template for tests

[ellnix]

This should stop configlet's warnings about missing tests. Please let me know if things like this are worth doing or if I should just let old code be as long as it's working.

[no important files changed]

[github-actions]

This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested.

If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos.

[no important files changed]

For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping @exercism/maintainers-admin in a comment. Thank you!

[senekor]

Looks great. I usually try to write the template in a way to keep the diff small, unless there is a reason not to. In this case, it looks like it should be straight-forward to make the test file essentially identical to what it was before.

This should stop configlet's warnings about missing tests. Please let me know if things like this are worth doing or if I should just let old code be as long as it's working.

I do think this is worth doing! A lot of time I invested in maintaining the Rust track was writing the exercise generator and lifting exercises up to it one-by-one. I'm happy if you keep that effort going.

Just a heads-up though, some of the exercises are very difficult to use with the exercise generator, for various reasons:

• problem-specifications has a nasty, inconsistent data structure
• existing exercise design is completely different from what the tests in problem-specifications expect
• probably more I'm forgetting

I definitely recommand checking the tests in problem-specifications and the exerice design first, before starting to work on a complicated template. I had to abandon optimistic work in frustration more than once.

In some cases, it may be more appropriate to just update the tests (and more importantly, tests.toml) manually.

[ellnix]

Looks great. I usually try to write the template in a way to keep the diff small, unless there is a reason not to. In this case, it looks like it should be straight-forward to make the test file essentially identical to what it was before.

The original had the advantage of manually formatting each test case, and based on the length of the input it decides between

assert_eq!(encode("text"), "encoded")

and

assert_eq!(
  encode("text"),
  "encoded"
)

An alternative could be adding a cargo fmt step after rendering the template, but for now I'll just update all of the cases to use the second form. I don't think there's a setup I can use to make them identical to the ones written by hand (without some very ugly tera).

Looks like update-exercise already runs rustfmt, this is some excellent tooling.

I do think this is worth doing! A lot of time I invested in maintaining the Rust track was writing the exercise generator and lifting exercises up to it one-by-one. I'm happy if you keep that effort going.
... (and more importantly, tests.toml) manually.

That's great, I'm glad this is important. Seems like a very good way to get familiar with the workflow. I'll spam you with more requests for review in the coming days, until (if ever) we're both comfortable with me doing this kind of routine maintenance without bothering you.

Just a heads-up though, some of the exercises are very difficult to use with the exercise generator, for various reasons:

* problem-specifications has a nasty, inconsistent data structure

* existing exercise design is completely different from what the tests in problem-specifications expect

* probably more I'm forgetting

I definitely recommand checking the tests in problem-specifications and the exerice design first, before starting to work on a complicated template. I had to abandon optimistic work in frustration more than once.

In some cases, it may be more appropriate to just update the tests

I saw that with bowling, I don't know if it's doable, but it does look extremely complex. For what it's worth, I don't plan to touch any exercise that I haven't solved, and I always copy the test file on my own solution to see if it works. But that still means I have to check more complex cases closely to make sure that tests break when they are supposed to. Also 31 test cases 😱

[ellnix]

Added separate commits for context, since everything is squashed anyway.

[senekor]

Looks like update-exercise already runs rustfmt, this is some excellent tooling.

Thanks! 😍

I think the best part about this is that you can mostly focus on making the template somewhat readable, rather than having to create an ugly mess just to get the output perfectly right.

I'll spam you with more requests for review in the coming days, until (if ever) we're both comfortable with me doing this kind of routine maintenance without bothering you.

That's perfectly fine. If I'm too busy it will just take a moment for me to respond. But that's open source.

When I was the only maintainer, exercism contributors in the group "guardians" would do reviews for me. Now that we're two, we always have to review each other's work.