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

Add elapsed runtime tracking for verbose spec output, fixes #2854 #2855

Closed
wants to merge 2 commits into from

Conversation

mperham
Copy link
Contributor

@mperham mperham commented Jun 16, 2016

It currently looks like this:

Sidekiq::CLI
  parses
  handles no arguments gracefully
ruby compatibility
  API
    works with Ruby-based retries: 0.152789s
Sidekiq::Heartbeat
  beats
Sidekiq::Job
  serialization
    deserializes a simple job: 0.151404s
    deserializes a retry: 0.149071s
Sidekiq::Logger
  basics
    logs
    allows multi-level context

Printing the elapsed time after every line makes for noisy output. I added an arbitrary threshold of 10ms, any tests above this runtime will print out. Better ideas?

@asterite
Copy link
Member

It's a good start, thanks!

But given that you want to find what are the slowest tests ran, we could maybe add a --time option that displays all tests sorted by how much time they took. I'd actually use that a lot, for example to find what are the slowest specs on the compiler itself and try to reduce their them.

Otherwise you'll have to manually sort the times from the output.

@mperham
Copy link
Contributor Author

mperham commented Jun 16, 2016

rspec has a --profile mode which outputs the top 10 slowest specs in the suite. I think that's a better approach than printing the time in verbose mode: you typically want to see the slowest tests, not just all runtimes. Agreed?

@asterite
Copy link
Member

Sounds good. Can you choose how many slowest specs to show?

@mperham
Copy link
Contributor Author

mperham commented Jun 16, 2016

What do you think about --slow=20 as the parameter to show the slowest 20 specs, defaulting to 10?

@asterite
Copy link
Member

--profile reads better. We could do --profile=10 or we can start with just --profile and a fixed 10 and later improve on that, if ever needed :-)

@mperham
Copy link
Contributor Author

mperham commented Jun 16, 2016

Any tips on how to add an option default, so the user can pass --profile or -p 20, where the first version would default to 10?

@asterite
Copy link
Member

Maybe:

require "option_parser"

OptionParser.parse! do |parser|
  parser.on("-p", "--profile N", "desc") do |value|
    p value # empty string means nothing -p was used
  end
end

Or:

require "option_parser"

OptionParser.parse! do |parser|
  parser.on("-p", "--profile", "desc") do
    puts "bare"
  end
  parser.on("--profile N", "desc") do |value|
    p value
  end
end

It seems you can't pass "-p=10" nor "-p 10", but you can pass "-p10" as command line args. I can't remember now why that's like that. Otherwise you can use:

require "option_parser"

OptionParser.parse! do |parser|
  parser.on("-p", "--profile", "desc") do
    puts "bare"
  end
  parser.on("-p N", "--profile N", "desc") do |value|
    p value
  end
end

but for the second case you must use -p10 or --profile 10 or --profile=10, but you can't use -p=10.

Too many options to choose now 😊

@mperham
Copy link
Contributor Author

mperham commented Jun 16, 2016

Updated

@jhass jhass added this to the 0.18.1 milestone Jun 16, 2016
@jhass
Copy link
Member

jhass commented Jun 16, 2016

Merged as ab52258

Thank you!

@jhass jhass closed this Jun 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants