Further testing to oof cli

[demfabris]

@marcospb19 So i'm kinda having a hard time here. Not sure if parse_args_from is misbehaving. 😕

Please have a look at these test attempts

Also, how should we approach these tests?
I did two variants, let me know which approach is best (if you like the second best i think we should consider using assert_cmd and assert_fs

[marcospb19]

It's more for the direction of the first test you made. Here are some examples I was elaborating.

fn gen_args(text: &str) -> Vec<OsString> {
    let args = text.split_whitespace();
    args.map(OsString::from).collect()
}

fn test_cli(args: &str) -> crate::Result<ParsedArgs> {
    let args = gen_args(args);
    parse_args_from(args)
}

#[test]
fn test_cli_commands() {
    assert_eq!(test_cli("--help").unwrap().command, Command::ShowHelp);

    assert_eq!(test_cli("--version").unwrap().command, Command::ShowVersion);
    assert_eq!(test_cli("--version").unwrap().flags, oof::Flags::default());

    // Testing for errors
    // // Not currently possible because of PartialEq trait limits on io::Error
    // assert_eq!(
    //     test_cli("compress").unwrap_err(),
    //     Err(crate::Error::MissingArgumentsForCompression)
    // );
}

#[test]
fn test_cli_flags() {
    // --help and --version flags are considered commands that are ran over anything else
    assert_eq!(test_cli("--help").unwrap().flags, oof::Flags::default());
    assert_eq!(test_cli("--version").unwrap().flags, oof::Flags::default());

    // Just for reference:
    // pub struct Flags {
    //     pub boolean_flags: BTreeSet<&'static str>,
    //     pub argument_flags: BTreeMap<&'static str, OsString>,
    // }

    assert_eq!(test_cli("a b c -o hey --yes").unwrap().flags, oof::Flags {
        boolean_flags: vec!["yes"].into_iter().collect(),
        argument_flags: vec![("--output", OsString::from("hey"))].into_iter().collect(),
    });
}

[marcospb19]

It looks like there is already an error with the -o not being detected.

I don't know exactly why.

But yeah the main idea for this testing part is to have lines like this:

    assert_eq!(test_cli(INPUT).unwrap().command, Command:: .. );
    assert_eq!(test_cli(INPUT).unwrap().command, Command:: .. );
    assert_eq!(test_cli(INPUT).unwrap().command, Command:: .. );
    assert_eq!(test_cli(INPUT).unwrap().command, Command:: .. );

With different inputs. Some with .unwrap_err(), covering the usage cases we mentioned in the readme.

I was thought this would be easier but we ran into some issues with some trait implementations, I pushed new commits solving some of then already.

[demfabris]

So i added a couple more tests, all passing.

Indeed seems to be a misbehaviour with that last assert_eq! in test_cli_flags.
It doesn't correctly parse the --output flag

[marcospb19]

Tomorrow I will try to review this and figure out the --output flag problem, I have no idea what the problem is.

[marcospb19]

@fabricio7p I have now fixed the --output error, we were using take_arg which removes the flag from our oof::Flags struct, that's why we couldn't find that later.

Not, by using .arg() instead, we clone (kindof) the content, and now the output_folder can be found in our Command::Decompress as well as oof::Flags.

I adapted the tests, and now they are passing correctly, sorry for the late response.

[demfabris]

Done. Sorry about that, i've had a busy week

[marcospb19]

No problem! You're the one helping here, thanks for your contribution, I was working on an big change on ouch compression and decompression system,.

Istead of loading everything to a Vec inbetween each compression or decompression, I can concatenate some decoder and encoder writers, to create a compression stream that writes directly into the final file.

Now ouch will support more than 2 extensions, .tar.gz.xz.bz.gz.gz will be possible, I just don't know when I'll be able to finish it, am having fever, even suspecting I got COVID.

~
Como você é brasileiro, se quiser manter contato, eu e Vinícius nos comunicamos pelo do telegram, no meu perfil aqui do GitHub tem meu username, que é @marcospb19 também, se quiser conversar por lá, só chamar :) , pode ser mais fácil ajudar novos PRs também com um canal mais fácil de conversação
~

[marcospb19]

Anyway, merging!