feature: adds "output" mode, resolves #270

[jrvidal]

• New: mode = "output.
• If output = "foobar" is specified for an "output" exercise, it runs a "test" against the expected output.
• An "output" exercise prints its output in the 🎉 Move on when you're ready screen.

Screenshots

After playing a while with this, I'm not entirely sold on the idea 😅 I think having expected output could be useful in a very exploratory exercise like "Get main to print Hello world! to the screen". But, in general, I feel like "test" exercises guide you better toward the answer. Take structs1.rs for instance and its hypothetical alternative:

structs1.rs

struct ColorClassicStruct {
    // TODO: Something goes here
}

struct ColorTupleStruct(/* TODO: Something goes here */);

#[derive(Debug)]
struct UnitStruct;

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn classic_c_structs() {
        // TODO: Instantiate a classic c struct!
        // let green =

        assert_eq!(green.name, "green");
        assert_eq!(green.hex, "#00FF00");
    }

    #[test]
    fn tuple_structs() {
        // TODO: Instantiate a tuple struct!
        // let green =

        assert_eq!(green.0, "green");
        assert_eq!(green.1, "#00FF00");
    }

    #[test]
    fn unit_structs() {
        // TODO: Instantiate a unit struct!
        // let unit_struct =
        let message = format!("{:?}s are fun!", unit_struct);

        assert_eq!(message, "UnitStructs are fun!");
    }
}

structs1.rs with "output"

struct ColorClassicStruct {
    // TODO: Something goes here
}

struct ColorTupleStruct(/* TODO: Something goes here */);

#[derive(Debug)]
struct UnitStruct;

fn main() {
    // TODO: Instantiate a classic c struct!
    // let green =
    println!("green.name = {}", green.name);
    println!("green.hex = {}", green.hex);

    // etc.
}

I don't think it works quite as well, since the learner has no clue what the value of green.name should be until they get the program to compile and see the Expected/Actual error message. And it'll be way harder to reach that point without the clue on what the fields of ColorClassicStruct should be. I suspect we could blame the exercise itself. Others, like if1.rs, might work better.

What I do think it works great is non-expected output exercises. Most of the "compile" exercises felt a bit anti-climatic. Once you get the program to compile, you can still play with it thanks to I AM NOT DONE, but you don't see the results of your tweaks. Even if we don't adopt mode="output", I think the default behavior of "compile" should be this.

So, summary of options:

1. Scrub this, make "compile" always print output.
2. Keep this PR as it is. It might be useful in future exercises, or maybe you have a strong opinion that some mode = "test" exercises should be converted.
   • If we keep it, we could still make "compile" always print as in (1) and
     reserve mode = "output" for mandatory expected output (i.e. change Mode::Output(Option<String>) to Mode::Output(String)).

[jrvidal]

This message doesn't make sense for Mode::Output(None) 🤦‍♀️

[jrvidal]

Why aren't there tests for failure cases?

The behavior of rustlings run for a mode="output" exercise with expected output is to simply run the program without running the "test harness". So I can't actually test the test harness itself 😞 I suppose this could be an argument in favor of actually running the comparison on rustling run.

[jrvidal]

@fmoko One little detail that I noticed: the verify_all_failure test case misled me a bit, since it only tests that some exercise fails to verify. Should we change the name?

[jrvidal]

Re-added this line, a regression introduced in #271 🙈

[shadows-withal]

I might be a month late, but I think the first option sounds good for now. How do you wanna continue with this, make the changes in this PR or open a new one?

[jrvidal]

I can make the changes in this PR 👍

[shadows-withal]

Looks good now! I'm trying to figure out how we wanna release this... it's definitely a breaking change, and there's some SemVer minor things laying around on master, so we could either do a minor release and then a major one a bit after or just coagulate all of it into a major release. What do you think?

[jrvidal]

Hm, usually I'd be inclined to push a minor and then a major, so people can avoid breakage if they want. However, given the way I assume most people consume rustlings (they clone it, work on it for a while, and probably never update the repo), I think it'd be fine to just release a major.