add success and fail to command response

[kbrock]

No description provided.

[Fryguy]

@kbrock Not sure I like the name .fail?...it doesn't mix with .success? (I would expect .fail? to align with .succeed?). I'm thinking .failure? is a better name.

[kbrock]

cool.

I like the methods succeed? and fail? or succeeded? failed?

This is to make specs read better

expect(x).to be_success
expect(x).to be_failure

Hmm, maybe if we could:

expect(x).to have_succeeded
expect(x).to have_failed

[chessbyte]

Even clearer would be

expect(x).to succeed
expect(x).to fail

[kbrock]

I'll play.

be_success is automatically added.
Maybe there are some other auto matchers that have better wording

[Fryguy]

As far as Travis goes, I think I have to change the whole thing to go against 2.1.1, so ignore the failures.

[kbrock]

only ref I have found is the predicates listed at rspec matchers.

expect(described_class.new("c", "o", "e", 0)).to be_success ==> .success?
expect(described_class.new("c", "o", "e", 0)).to be_a_success ==> .success?
expect(described_class.new("c", "o", "e", 0)).to have_success ==> .has_success?
expect(described_class.new("c", "o", "e", 0)).to has_success ==> .has_success?

be_a_success may be the best one here (without writing a matcher).

[kbrock]

@chessbyte expect(cmd_response).to be_a_success ?

[Fryguy]

Yes, be_a_success and be_a_failure read much nicer.

[cfme-bot]

Checked commit kbrock@7620666 with rubocop 0.21.0
2 files checked, 0 offenses detected
Everything looks good. 🍪