You can clone with
HTTPS or Subversion.
The improvement that "provide more accurate run time by registering start time before code is loaded" is great, but this (commit) cause a problem when Spork is used since the start time is set in the prefork block of Spork and duration will then be calculated from this time so it ends up in always increasing duration time.
Maybe the solution should come from Spork, like setting $rspec_start_time ||= Time.now at the top of the Spork.each_run block (as the temporary fix you gave in this guard-rspec issue?
$rspec_start_time ||= Time.now
Thanks in advance!
Thanks for reporting this here.
I don't think using an internal rspec global variable from spork would be a good solution. More likely I'd want something like RSpec.start_recording_time or some such. Any ideas on the name?
@timcharper - do you think it would a reasonable thing for spork to do to call RSpec.start_recording_time (or similar) at the beginning of each run?
You're right about the internal global variable! :)
Maybe RSpec.set_start_time (or RSpec.reset_start_time?) is more appropriate since it will (re)set $rspec_start_time?
I have a related problem, which is that I actually need the spec-only runtime. To monitor Raptor, I plot many metrics across commits, including spec runtime. I don't care about load time for this metric; I just want to know whether the specs themselves get slow.
How about this as a proposed solution to both my problem and the spork one:
Alternatively, we could restore to the pre 2.7 reporting by default, and add an option to report the load time separately.
I was very tempted to suggest that. I'm torn because I love the idea of putting more emphasis on end-to-end runtime, but it's also nonstandard and not backwards compatible (with my metrics, for example).
Alterate to the previous alternative - make the option "include rspec's boot time in the time report"
Restore reported run time to begin after files are loaded.
- was causing problems for spork users and others.
- closes #475.
This reverts commit fd04952, with
a couple of minor changes/additions.