Skip to content
This repository was archived by the owner on Nov 30, 2024. It is now read-only.

Include error count for errors occurring outside examples in summary #2351

Merged
merged 4 commits into from
Nov 15, 2016

Conversation

JonRowe
Copy link
Member

@JonRowe JonRowe commented Nov 15, 2016

Improve our handling of errors which occur in suite hooks by displaying a count of errors occurred in the summary.

As suggested in #2329

/cc @myronmarston

Copy link
Member

@myronmarston myronmarston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the x errors occurred output is confusing. Some test runners (such as minitest and test-unit) differentiate between "failures" (generally an assertion/expectation failure) and "errors" (any other kind of error raised in a test). We've never differentiated that in our output like those runners do, but we do use failure vs error terminology with aggregate_failures:

https://github.com/rspec/rspec-expectations/blob/40b61c44d7ce36bf59dd09c0d0094bb19a1c1f99/spec/rspec/expectations/failure_aggregator_spec.rb#L295

I think there are two ways we can go with this:

  1. Come up with some more specific, accurate language (such as x errors occurred while loading the suite)
  2. Keep the more generic "errors" language but do things like the other test runners and include any non-expectation failure in that count

If we go with the first option I think we should also not include this in the output if we have no errors to report. After all, getting errors at spec file load time is a rarity, and most of the time reporting 0 errors occurred is just noise.

Thoughts?

@@ -281,8 +281,10 @@ def fully_formatted
# @attr pending_examples [Array<RSpec::Core::Example>] the pending examples
# @attr load_time [Float] the number of seconds taken to boot RSpec
# and load the spec files
# @attr errors [Integer] the number of errors that have occurred processing
# the spec suite
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name errors is a bit mis-leading -- usually I'd expect a field called errors to be an array of errors but here it's just a count. And it's not a count of all errors -- it's a count only of some errors.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The doc still says errors...

@JonRowe
Copy link
Member Author

JonRowe commented Nov 15, 2016

Keep the more generic "errors" language but do things like the other test runners and include any non-expectation failure in that count

It does that, it hooks into the reporter with a method named after exactly that, these are just the only non expectation failure we currently have?

@myronmarston
Copy link
Member

It does that, it hooks into the reporter with a method named after exactly that, these are just the only non expectation failure we currently have?

No, the reporter method name is notify_non_example_exception which is for exceptions that happen outside of an example, regardless of if they are expectation failures or some other kind of error.

The failures vs errors distinction I was talking about has to do with the type of exception -- e.g. expect(1).to eq 2 raises an exception categorized as a failure because it is an expectation that failed (e.g. something you are specifically checking for in a spec) where as any other kind of exception is categorized as an error.

@JonRowe
Copy link
Member Author

JonRowe commented Nov 15, 2016

We count an error during an example as a failure, I'm happy to change the wording to n errors occurred outside of examples if thats better?

@myronmarston
Copy link
Member

That is better.

@JonRowe
Copy link
Member Author

JonRowe commented Nov 15, 2016

Done!

Copy link
Member

@myronmarston myronmarston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple more comments...

@@ -281,8 +281,10 @@ def fully_formatted
# @attr pending_examples [Array<RSpec::Core::Example>] the pending examples
# @attr load_time [Float] the number of seconds taken to boot RSpec
# and load the spec files
# @attr errors [Integer] the number of errors that have occurred processing
# the spec suite
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The doc still says errors...

@@ -18,6 +18,7 @@ def initialize(configuration)
@failed_examples = []
@pending_examples = []
@duration = @start = @load_time = nil
@errors = 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about calling this non_example_exception_count?

@JonRowe
Copy link
Member Author

JonRowe commented Nov 15, 2016

Updated again

@myronmarston
Copy link
Member

Merge away.

@JonRowe JonRowe merged commit 0c8db72 into master Nov 15, 2016
@JonRowe JonRowe deleted the errors_occured branch November 15, 2016 21:58
@yujinakayama
Copy link
Member

Shouldn't the 0 examples, 0 failures, 3 errors occurred outside of examples line be red when there're errors outside of examples?

summary

MatheusRich pushed a commit to MatheusRich/rspec-core that referenced this pull request Oct 30, 2020
MatheusRich pushed a commit to MatheusRich/rspec-core that referenced this pull request Oct 30, 2020
Include error count for errors occurring outside examples in summary
MatheusRich pushed a commit to MatheusRich/rspec-core that referenced this pull request Oct 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants