This repository has been archived by the owner on Dec 29, 2021. It is now read-only.
Fluent Output Tests Look off with rustfmt #70
Labels
Comments
|
RE Accepting predicates (from #41) One thing in favor of accepting predicates as parameters is that someone wanted to pass multiple predicates at once which is more of an issue with contains and negated contains/is and not is.
I think there is still value in specialized predicates for better error reporting. We could just use From to auto-convert a Fn into one of the predicates. |
|
Error reporting is a good point! We should aim for nice errors, as that is what people are using the crate for. I didn't specify what |
epage
added a commit
to epage/assert_cli
that referenced
this issue
Oct 28, 2017
rustfmt will split long builers across lines, even when that breaks
logical grouping.
For example
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr().contains("foo-bar-foo")
.unwrap();
```
will be turned into
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr()
.contains("foo-bar-foo")
.unwrap();
```
which obscures intent.
Normally, I don't like working around tools but this one seems
sufficient to do so.
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr(assert_cli::Output::contains("foo-bar-foo"))
.unwrap();
```
Pros
- More consistent with `with_env`
- Can add support for accepting arrays
- Still auto-complete / docs friendly
- Still expandable to additional assertions without much duplication or
losing out on good error reporting
Cons
- More verbose if you don't `use assert_cli::{Assert, Environment, Output}`
Alternatives
- Accept distinct predicates
- e.g. `.stderr(assert_cli::Is::text("foo-bar-foo"))`
- e.g. `.stderr(assert_cli::Is::not("foo-bar-foo"))`
- Strange `text` function
- More structs to `use`
- Less auto-complete / docs friendly (lacks contextual discovery or
whatever the UX term is)
Fixes assert-rs#70
BREAKING CHANGE: `.stdout().contains(text)` is now
`.stdout(assert_cli::Output::contains(text)`, etc.
4 tasks
epage
added a commit
to epage/assert_cli
that referenced
this issue
Oct 28, 2017
rustfmt will split long builers across lines, even when that breaks
logical grouping.
For example
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr().contains("foo-bar-foo")
.unwrap();
```
will be turned into
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr()
.contains("foo-bar-foo")
.unwrap();
```
which obscures intent.
Normally, I don't like working around tools but this one seems
sufficient to do so.
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr(assert_cli::Output::contains("foo-bar-foo"))
.unwrap();
```
Pros
- More consistent with `with_env`
- Can add support for accepting arrays
- Still auto-complete / docs friendly
- Still expandable to additional assertions without much duplication or
losing out on good error reporting
Cons
- More verbose if you don't `use assert_cli::{Assert, Environment, Output}`
Alternatives
- Accept distinct predicates
- e.g. `.stderr(assert_cli::Is::text("foo-bar-foo"))`
- e.g. `.stderr(assert_cli::Is::not("foo-bar-foo"))`
- Strange `text` function
- More structs to `use`
- Less auto-complete / docs friendly (lacks contextual discovery or
whatever the UX term is)
Fixes assert-rs#70
BREAKING CHANGE: `.stdout().contains(text)` is now
`.stdout(assert_cli::Output::contains(text)`, etc.
epage
added a commit
to epage/assert_cli
that referenced
this issue
Oct 28, 2017
rustfmt will split long builers across lines, even when that breaks
logical grouping.
For example
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr().contains("foo-bar-foo")
.unwrap();
```
will be turned into
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr()
.contains("foo-bar-foo")
.unwrap();
```
which obscures intent.
Normally, I don't like working around tools but this one seems
sufficient to do so.
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr(assert_cli::Output::contains("foo-bar-foo"))
.unwrap();
```
Pros
- More consistent with `with_env`
- Can add support for accepting arrays
- Still auto-complete / docs friendly
- Still expandable to additional assertions without much duplication or
losing out on good error reporting
Cons
- More verbose if you don't `use assert_cli::{Assert, Environment, Output}`
Alternatives
- Accept distinct predicates
- e.g. `.stderr(assert_cli::Is::text("foo-bar-foo"))`
- e.g. `.stderr(assert_cli::Is::not("foo-bar-foo"))`
- Strange `text` function
- More structs to `use`
- Less auto-complete / docs friendly (lacks contextual discovery or
whatever the UX term is)
Fixes assert-rs#70
BREAKING CHANGE: `.stdout().contains(text)` is now
`.stdout(assert_cli::Output::contains(text)`, etc.
epage
added a commit
to epage/assert_cli
that referenced
this issue
Oct 28, 2017
rustfmt will split long builers across lines, even when that breaks
logical grouping.
For example
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr().contains("foo-bar-foo")
.unwrap();
```
will be turned into
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr()
.contains("foo-bar-foo")
.unwrap();
```
which obscures intent.
Normally, I don't like working around tools but this one seems
sufficient to do so.
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr(assert_cli::Output::contains("foo-bar-foo"))
.unwrap();
```
Pros
- More consistent with `with_env`
- Can add support for accepting arrays
- Still auto-complete / docs friendly
- Still expandable to additional assertions without much duplication or
losing out on good error reporting
Cons
- More verbose if you don't `use assert_cli::{Assert, Environment, Output}`
Alternatives
- Accept distinct predicates
- e.g. `.stderr(assert_cli::Is::text("foo-bar-foo"))`
- e.g. `.stderr(assert_cli::Is::not("foo-bar-foo"))`
- Strange `text` function
- More structs to `use`
- Less auto-complete / docs friendly (lacks contextual discovery or
whatever the UX term is)
Fixes assert-rs#70
BREAKING CHANGE: `.stdout().contains(text)` is now
`.stdout(assert_cli::Output::contains(text)`, etc.
Closed
epage
added a commit
to epage/assert_cli
that referenced
this issue
Feb 2, 2018
rustfmt will split long builers across lines, even when that breaks
logical grouping.
For example
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr().contains("foo-bar-foo")
.unwrap();
```
will be turned into
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr()
.contains("foo-bar-foo")
.unwrap();
```
which obscures intent.
Normally, I don't like working around tools but this one seems
sufficient to do so.
```rust
assert_cli::Assert::command(&["ls", "foo-bar-foo"])
.fails()
.and()
.stderr(assert_cli::Output::contains("foo-bar-foo"))
.unwrap();
```
Pros
- More consistent with `with_env`
- Can add support for accepting arrays
- Still auto-complete / docs friendly
- Still expandable to additional assertions without much duplication or
losing out on good error reporting
Cons
- More verbose if you don't `use assert_cli::{Assert, Environment, Output}`
Alternatives
- Accept distinct predicates
- e.g. `.stderr(assert_cli::Is::text("foo-bar-foo"))`
- e.g. `.stderr(assert_cli::Is::not("foo-bar-foo"))`
- Strange `text` function
- More structs to `use`
- Less auto-complete / docs friendly (lacks contextual discovery or
whatever the UX term is)
Fixes assert-rs#70
BREAKING CHANGE: `.stdout().contains(text)` is now
`.stdout(assert_cli::Output::contains(text)`, etc.
|
In addition to the existing PR exploring this, #98 would also possibly resolve this. |
|
Addressed in assert_cmd |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The API looks weird when run through rustfmt because it puts each function on a separate line, so it clouds up what the predicate is operating on
Environmentand take in a predicate parameter(Split of from #41)
The text was updated successfully, but these errors were encountered: