Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boolean OR? #108

Closed
jyn514 opened this issue Oct 16, 2020 · 1 comment
Closed

boolean OR? #108

jyn514 opened this issue Oct 16, 2020 · 1 comment

Comments

@jyn514
Copy link

jyn514 commented Oct 16, 2020

I want to say something like this:

        let assert = Command::new("cargo").args(&["clean", "-p", "simple_project"])
            .current_dir("./tests/simple_project")
            .assert()
            .success()
            .or().stdout("package ID specification `simple_project` matched no packages");

But I don't see an or() function, or any function taking an arbitrary Predicate instead of a built-in assertion. In the meantime I can use https://doc.rust-lang.org/std/process/struct.Command.html#method.output, but it would be nice to have something built-in.

@epage
Copy link
Contributor

epage commented Oct 17, 2020

As of right now, we can only handle predicates on one field at a time. I'm doubtful we'll be enabling ore complex ones.

In considering more complex expressions, one of the problems is the termination case, what causes us to evaluate all of it.

assert_cmd (at that time assert_cli) supported building expressions (before the execution happened). We simplified to being a thinner wrapping around Command but without us carrying any data because of that, we had to move the assertions to happen after the command runs. The problem we ran into was evaluating the expression. Its very easy to forget (though maybe we could play with must_use).

Then next problem is naming.

After that is how do we enable these arbitrary declarative-like logical conditions. Do we explicitly not support nested expressions? If we support them, what would the API look like?

With all of this, what is the ergonomics of the API compared to writing a more imperative logic.

@epage epage closed this as completed Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants