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

Ensure ExecutionResult timing is always populated #2144

Merged
merged 3 commits into from
Dec 31, 2015
Merged

Conversation

soulcutter
Copy link
Member

In the case where RSpec does not handle an error (e.g. SystemExit), we still need to capture the example timing data in order not to break profiling information that may get generated via --profile using those values.


# @api private
# Ensure that finish_time and run_time have values.
def finalize_run_time(clock)
Copy link
Member Author

Choose a reason for hiding this comment

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

This could be named better. Suggestions welcome

Copy link
Member

Choose a reason for hiding this comment

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

Remove the comment and rename ensure_timing_set?

Copy link
Member Author

Choose a reason for hiding this comment

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

Better name idea! Thanks.

There does need to be some comment there, though, in order to keep 100% documentation coverage (even though it's api private). At least that's what CI tells me :)

@soulcutter soulcutter force-pushed the abort-with-profile branch 4 times, most recently from ffd5414 to d36fc00 Compare December 30, 2015 01:20
@soulcutter
Copy link
Member Author

Hmm, I don't believe that CI failure relates to this set of changes. Incorporated your suggestions otherwise, @JonRowe

# @api private
# Populates finished_at and run_time if it has not yet been set
def ensure_timing_set(clock)
finished_at || calculate_run_time(clock.now)
Copy link
Member

Choose a reason for hiding this comment

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

This works, but feels like an abuse of ||. Typically || is used to return one of two values but here we don't care about the return value -- this method is a command method, not a query method, and at the call site the return value is ignored. Using || works because it short-circuits and does not evaluate the right expression if finished_at is set...but that feels like an abuse of ||. I think it'd be far more clear if written as:

calculate_run_time(clock.now) unless finished_at

After all, the goal of this method is to calculate the run time unless finished_at is already set -- and using unless allows us to state that more directly.

Copy link
Member Author

Choose a reason for hiding this comment

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

I had originally written this as finished_at or calculate_run_time(clock.now) in the spirit of http://devblog.avdi.org/2014/08/26/how-to-use-rubys-english-andor-operators-without-going-nuts/ - but rubocop prohibits using or so I tweaked it to || (which works, but… yeah, what you said).

Anyway, I agree that the unless version is more-expressive - thanks for pointing that out.

In the case where RSpec does not handle an error (e.g. SystemExit), we
still want to capture the example timing data to not break profiling
information that may get generated via `--profile`.

Fixes #2142
@JonRowe
Copy link
Member

JonRowe commented Dec 31, 2015

👍

JonRowe added a commit that referenced this pull request Dec 31, 2015
Ensure ExecutionResult timing is always populated
@JonRowe JonRowe merged commit a9f9d5a into master Dec 31, 2015
@JonRowe JonRowe deleted the abort-with-profile branch December 31, 2015 05:54
MatheusRich pushed a commit to MatheusRich/rspec-core that referenced this pull request Oct 30, 2020
Ensure ExecutionResult timing is always populated
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

Successfully merging this pull request may close these issues.

3 participants