don't print the duration in quiet mode

[richarda]

This attempts to resolve #816
I'm not able to remove the referenced hack just yet, but I'll keep working on it.

[richarda]

@mattwynne does this do it for the Tcl situation or do we need to be able to remove the duration from --dry-run features too?

[mattwynne]

I wonder if we still need that features.duration check. Could it ever be nil? Looks quite defensive.

[mattwynne]

LGTM @richarda. How come you can't remove the hack?

[richarda]

@mattwynne in the current state of this branch, removing the line that substitutes a fixed duration of 0m0.012 leaves a handful of scenarios failing with what seems to be their actual duration. I was just still thinking what might be a good way to address that. The failing scenarios are using Then it should pass/fail with exactly Do you think some of those steps might not actually require an exact output comparison if the purpose involves only a portion of the output? Should dry-run print a duration?

These are are the tests that break without that substitution:

Failing Scenarios:
cucumber -p ruby_2_0 features/docs/cli/dry_run.feature:8 # Scenario: With a failing step
cucumber -p ruby_2_0 features/docs/cli/dry_run.feature:30 # Scenario: In strict mode
cucumber -p ruby_2_0 features/docs/cli/dry_run.feature:52 # Scenario: In strict mode with an undefined step
cucumber -p ruby_2_0 features/docs/defining_steps/table_diffing.feature:7 # Scenario: Extra row
cucumber -p ruby_2_0 features/docs/exception_in_before_hook.feature:44 # Scenario: Handle Exception in Before hook for Scenario with Background
cucumber -p ruby_2_0 features/docs/formatters/usage_formatter.feature:60 # Scenario: Run with --expand --format usage
cucumber -p ruby_2_0 features/docs/formatters/usage_formatter.feature:86 # Scenario: Run with --format stepdefs
cucumber -p ruby_2_0 features/docs/wire_protocol/table_diffing.feature:99 # Scenario: Invoke a step definition which asks for an immediate diff that fails
cucumber -p ruby_2_0 features/docs/writing_support_code/tagged_hooks.feature:34 # Scenario: omit tagged hook
cucumber -p ruby_2_0 features/docs/writing_support_code/tagged_hooks.feature:54 # Scenario: omit tagged hook
cucumber -p ruby_2_0 features/docs/writing_support_code/tagged_hooks.feature:69 # Scenario: Omit example hook

[mattwynne]

You're right actually, it seems nonsensical to get the duration of a dry-run, so I think it would be OK for that to imply quiet.

[mattwynne]

Can you review the other ones to see whether it would make sense just to add --quiet to the command run on the When step? A quick scan over them looks like that would be OK.

[richarda]

Yes. I'll review those scenarios and take a look at dry-run.

[brasmusson]

@mattwynne You said yourself that Then it should pass with exactly: is preferable to Then it should pass with: since it gives much better feedback. If/When defining a feature to check the indentation for source references for Scenario Outlines in expand mode (where we have known problems), --quiet cannot be used, and the it is only "the hack" that enables the use of Then it should pass with exactly:.

If you really want to remove "the hack", then a --no-duration option is needed, so the source and/or snippets still can be checked with Then it should pass with exactly:.

[mattwynne]

Sounds like @brasmusson has thought about this more than me, and we should have a separate --no-duration flag that's implied by --quiet. Right?

[richarda]

@mattwynne when I ran the build locally against the latest cucumber-ruby-core from github, I got similar failures to what Travis is reporting on this PR. When I ran it against the released version of the core, tests pass. Is that true for you?

[richarda]

I'm good with --no-duration implied by --quiet. I also like --dry-run implying --no-duration as well.

[mattwynne]

Has it really been since March?! I've been too busy.

Thanks for your contribution @richarda, sorry to have stalled on this for so long.

[richarda]

Ha! No problem. I was just here looking at open issues again too.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.